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第 一 部 分 ”大 旗 不 挥 ， 谁 敢 冲 锋 一 一 6 大 设计 原则 全 新 解读 
第 1 章 ”单一 职责 原则 
1.1 我 是 “ 牛 ” 类 ， 我 可 以 担任 多 职 吗 
1.2 绝 杀 技 ， 打 破 你 的 传统 思维 
1.3 ”我 单纯 ， 所 以 我 快乐 
1.4 最 佳 实践 
第 2 章 ”里 氏 替 换 原则 
2.1 爱 恨 纠 锡 的 父子 关系 
2.2 纠纷 不 断 ， 规 则 压制 
2.3 最 佳 实践 
第 3 章 ”依赖 倒置 原则 
3.1 ”依赖 倒置 原则 的 定义 
3.2 言 而 无 信 ， 你 太 需 要 契约 
3.3 ”依赖 的 三 种 写法 
3.4 最 佳 实践 
第 4 章 ”接口 隔离 原则 
4.1 接口 隔离 原则 的 定义 
4.2 美女 何其 多 ， 观 点 各 不 同 





4.3 保证 接口 的 纯洁 性 








5.1 迪 米 特 法 则 的 定义 
5.2 我 的 知识 你 知道 得 越 少 越 好 








6.1 开 闭 原则 的 定义 

6.2 ” 开 闭 原则 的 庐山 真面目 

6.3 王 弘 . 用 , 

6.4 
EA | 





7.4 ” 单 例 模式 的 扩展 


















8.2 工厂 方 法 模式 的 定义 
8.3 ”工厂 方法 模式 的 应 用 





第 9 章 ”抽象 工厂 模式 
9.1 女 娲 的 失误 





第 12 章 ”代理 模式 
12.1 我 是 游戏 至 尊 


12.2 ”代理 模式 的 定义 
12.3 ”代理 模式 的 应 用 
12.4 ”代理 模式 的 扩展 
12.5 最 佳 实践 








14.2 ”中 介 者 模式 的 定义 
14.3 ”中 介 者 模式 的 应 用 





14.4 中 介 者 模式 的 实际 有 
14.5 ”最 佳 实践 





15.1 项 目 经 理 也 难当 
15.2 ”命令 模式 的 定义 





命令 模式 的 应 用 
15.4 ”命令 模式 的 扩展 
15.5 最 佳 实践 

第 16 章 ”责任 链 模 式 
16.1 古代 妇女 的 柳 锁 一 一 “三 从 四 德 ” 


15.3 














第 18 章 ”策略 模式 
18.1 刘备 江东 事 妻 ，j 








19.2 适配器 模式 的 定义 
19.3 ”适配器 模式 的 应 用 








20.3 ”迭代 器 模式 的 应 用 
20.4 最 佳 实践 
第 21 章 ”组 合 模 式 
21.2 组合 模式 的 定义 
a 





第 22 章 “观察 者 模式 
22.1 韩非子 身边 的 
22.4 
22.5 最 佳 实践 





23.1 我 要 





23.3 ”门面 模式 的 应 用 
23.4 ”门面 模式 的 注意 事 
23.5 ”最 佳 实践 

第 24 章 ”备忘录 模式 
24.1 如 此 追 女孩 子 ， 你 还 不 乐 
24.2 ”备忘录 模式 的 定义 











24.3 备忘录 模式 的 应 用 





25.3 





26.3 ”状态 模式 的 应 用 
解释 器 模式 
27.1 四 则 运算 你 会 
27.2 解释 器 模式 的 定义 
27.3 ”解释 器 模式 的 应 用 
27.4 ”最 佳 实践 
第 28 章 ” 享 元 模式 




















2 我 有 一 个 执 相 ,,, 
29.2 ”桥梁 模式 的 定义 








30.1 工厂 方法 模式 VS 建造 者 模式 











8 式 V5 装 作 模 式 








章 ” 跨 战区 PK 





第 36 章 ”观察 者 模式 + 中 介 者 模式 
36.1 事件 触发 器 的 开发 








第 37 章 “MVC 框 架 
37.1 MVC 框 架 的 实现 











附录 23 种 设计 模式 彩 图 


为 什么 写 这 本 书 


2009 年 5 月 份 ， 我 在 JavaEye 上 发 了 一 个 帖子 ， 其 中 提 到 自己 已 经 工 
作 9 年 了 ， 总 觉得 这 9 年 不 应 该 就 这 么 荒废 了 ， 应 该 给 自己 这 9 年 的 工作 
写 一 个 总 结 ， 总 结 的 初稿 就 是 这 本 书 。 





在 谈 为 什么 写 这 本 书 之 前 ， 先 拌 抖 自己 前 9 年 的 职业 生涯 吧 。 大 学 
时 我 是 学 习 机 械 的 ， 当 时 计算 机 刚刚 热 起 来 ， 自 己 也 喜欢 玩 一 些 新 奇 的 
东西 ， 记 得 最 清楚 的 是 用 VB 写 了 一 个 自由 落体 的 小 程序 ， 模 拟 小 球 从 
桌面 掉 到 地 板 上 ， 然 后 计算 反弹 趋势 ， 很 有 成 就 感 。 于 是 2000 年 毕业 
时 ， 我 前 尖 了 脑袋 进入 了 I 开行 业 ， 成 为 了 一 名 真正 的 开 男 ， 干 着 起 得 比 
鸡 早 、 睡 得 比 狗 晚 的 程序 员工 作 ，IT 男 的 辛酸 有 谁 知晓 ! 

















坦白 地 说 ,我 的 性 格 比 较 沉 间 ， 属 于 典型 的 程序 员 型 间 骚 ， 比 较 适 
合 做 技术 研究 。 在 这 9 年 里 ， 项 目 管理 做 过 ， 系 统 分 析 做 过 ， 小 兵 当 
过 ， 团 队 领导 人 也 当 过 ， 但 至 今 还 是 一 个 做 技术 的 。 要 总 结 这 9 年 技术 
生涯 ， 总 得 写 点 什么 吧 ， 最 好 是 还 能 对 其 他 人 有 点 儿 用 的 。 那 写 什 么 好 
呢 ? Spring、Struts 等 工具 框架 类 的 书 太 多 太 多 ， 很 难 再 写 出 花样 来 ， 经 
过 一 番 思 考 ， 最 后 选择 了 一 个 每 一 位 技术 人 员 都 需要 掌握 的 、 但 普及 程 
度 还 不 是 非常 高 的 、 又 稍微 有 点 难度 的 主题 一 一 设计 模式 (Design 





























Pattern, DP) 。 


中 国人 有 不 破 不 立 的 思维 ， 远 的 如 秦 始 星 焚 书 坑 颂 、 项 羽 火 烧 阿 房 
家 ， 近 的 如 破 “ 四 旧 ”。 正 是 由 于 有 了 这 样 的 思想 ， 于 古 卑 能 改 的 就 改 ， 
不 能 改 的 就 推翻 重 写 ， 没 有 一 个 持续 开发 蓝图 。 为 什么 要 破 才能 立 呢 ? 
为 什么 不 能 持续 地 发 展 ? 你 说 这 是 谁 的 错 呢 ?是 你 染 构 师 的 错 ， 你 不 能 
持续 地 拥抱 变化 ， 这 是 一 个 系统 最 失败 的 地 方 。 那 怎么 才能 实现 拥抱 变 
化 的 理想 呢 ? 设计 模式 ! 








设计 模式 是 什么 ? 它 是 一 套 理论 ， 由 软件 界 的 先辈 们 (The Gang of 
Four: 包括 Erich Gamma、Richard Helm、Ralph Johnson、John 
Vlissides) 总 结 出 的 一 套 可 以 反复 使 用 的 经 验 ， 它 可 以 提高 代码 的 可 重 
用 性 ， 增 强 系 统 的 可 维护 性 ， 以 及 解决 一 系列 的 复杂 问题 。 做 软件 的 人 
都 知道 需求 是 最 难 把 握 的 ， 我 们 可 以 分 析 现 有 的 需求 ， 预 测 可 能 发 生 的 
变更 ， 但 是 我 们 不 能 控制 需求 的 变更 。 问 题 来 了 ， 既 然 需求 的 变更 是 不 
可 控 的 ， 那 如 何 拥抱 变化 呢 ? 幸运 的 是 ， 设 计 模 式 给 了 我 们 指导 ， 专 家 
们 首先 提出 了 6 大 设计 原则 ， 但 这 6 大 设计 原则 仅仅 是 一 系列 “口号 ”， 真 
正 付 诸 实施 还 需要 有 详尽 的 指导 方法 ， 于 是 23 种 设计 模式 出 现 了 。 








设计 模式 已 经 诞 近 20 年 了 ， 其 间 出 版 了 很 多 关于 它 的 经 典 著 作 ， 相 
信 大 家 都 能 如 数 家 珍 。 尽 管 有 这 么 多 书 ， 工 作 5 年 了 还 不 知道 什么 是 策 
略 模式 、 状 态 模 式 、 责 任 链 模式 的 程序 员 大 有 人 在 。 不 信 ? 你 找 个 机 会 
去 “虚心 ”地 请 教 一 下 你 的 同事 ， 看 看 他 对 设计 模式 有 多 少 了 解 。 不 要 告 








诉 我 要 翻 书 才 明 白 ! 设计 模式 不 是 工具 ， 它 是 软件 开发 的 哲学 ， 它 能 指 
导 你 如 何 去 设 计 一 个 优秀 的 架构 、 编 写 一 段 健壮 的 代码 、 解 决 一 个 复杂 
的 需求 。 





因为 它 是 软件 行业 的 经 验 总 结 ， 因 此 它 具 有 更 广泛 的 适应 性 ， 不 管 
你 使 用 什么 编程 语言 ， 不 管 你 遇 到 什么 业务 类 型 ， 设 计 模 式 都 可 以 自由 
地 “侵入 ”。 


因为 它 不 是 工具 ， 所 以 它 没 有 一 个 可 以 具体 测量 的 标尺 ， 完 全 以 你 
目 己 的 理解 为 准 ， 你 认为 目 己 多 了 解 它 ， 你 就 有 可 能 产生 多 少 的 优秀 代 
码 和 设计 。 











因为 它 是 指导 思想 ， 你 可 以 在 此 基础 上 上 自由 发 挥 ， 甚 至 是 自己 设计 
出 一 套 设计 模式 。 





世界 上 最 难 的 事 有 两 件 : 一 是 让 人 心甘情愿 地 把 钱 掏 出 来 给 你 ， 二 
是 把 自己 的 思想 灌输 到 别人 的 脑子 里 。 设 计 模 式 就 属于 第 二 种 ， 它 不 是 
一 种 具体 的 技术 ， 不 像 Struts、Spring、Hibernate 等 框架 。 一 个 工具 用 久 
了 可 以 熟 能 生 巧 ， 就 像 砌 墙 的 工人 一 样 ， 长 年 累 月 地 砌 墙 ， 他 也 知道 如 
何 把 墙 砌 整齐 ， 如 何 多 快 好 省 地 干 活 ， 这 是 一 个 人 的 本 能 。 我 们 把 
Struts 用 得 很 渔 ， 把 Spring 用 得 很 顺手 ， 这 非常 好 ， 但 这 只 是 一 个 合格 的 
程序 员 应 该 具备 的 基本 能 力 ! 于 是 我 们 被 冠 以 代码 工人 《Code 
软件 行业 的 体力 劳动 者 。 








Worker ) 





如 果 你 通晓 了 这 23 种 设计 模式 就 不 同 了 ， 你 可 以 站 在 一 个 更 高 的 层 
次 去 鞠 析 程序 代码 、 软 件 设计 、 架 构 ， 完 成 从 代码 工人 到 架构 师 的 蜡 
变 。 注 意 ， 我 说 的 是 “通晓 "， 别 告诉 我 你 把 23 种 设计 模式 的 含义 、 适 应 
性 、 优 缺点 都 搞 清 楚 了 就 是 通晓 。 错 了 ! 没有 工作 经 验 的 积累 是 不 可 能 
真正 理解 设计 模式 的 ， 这 就 像 大 家 小 时 候 一 直 不 明白 为 什么 公公 妈妈 要 
工作 而 不 能 每 天 陪 上 自己 玩 一 样 。 

















据说 有 的 大 学 已 丝 开 了 设计 模式 这 门 课 ， 如 果 仅 仅 是 几 竺 读 ， 让 学 
生 对 设计 模式 有 一 个 初步 的 了 解 ， 我 觉得 并 无 不 受 ， 但 如 果 是 专门 的 一 
门 读 程 ， 我 建议 取消 它 ! 因为 对 一 个 尚 无 项 目 开 发 经 验 的 学 生来 说 ， 理 
解 设计 模式 不 是 一 般 困 难 ， 而 是 非常 非常 困难 ! 之 前 没有 任何 的 实战 经 
验 ， 之 后 也 没有 可 以 立即 付 诸 实践 的 场景 ， 这 样 能 理解 设计 模式 吗 ? 











在 编写 本 书 之 前 ，23 种 设计 模式 我 都 用 过 ， 而 且 还 算 比 较 熟 练 ， 但 
是 当真 正 要 写 到 书 中 时 ， 感 觉 心 里 没 谱 儿 了。 这 个 定义 是 这 样 的 吗 ? 是 
需要 用 抽象 类 还 是 应 该 用 接口 ? 为 什么 在 这 里 不 能 抽取 抽象 呢 ? 为 什么 
在 实际 项 目 中 这 个 模式 要 如 此 旷 化 ?这 类 小 问题 有 时 候 很 纠结 ， 需 要 花 
费 大 量 的 精力 和 时 间 去 分 析 和 确认 。 所 以 ， 在 写作 的 过 程 中 我 有 过 很 多 
忱 请 ， 担 心 书 中 会 有 太 多 瑕 疫 ， 这 种 忧 展现 在 仍然 存在 。 遇 到 挫折 的 时 
候 也 气 锰 过 ， 但 是 我 坚信 一 句 话 :“ 开 志 没 有 回头 盘 ， 回 头 即 是 空 ， 妈 
然 已 经 开始 ， 就 一 定 要 圆满 完成 














第 2 版 与 第 1 版 的 区 别 


本 书 是 第 2 版 ， 在 写作 中 吸取 了 读者 对 上 一 版 的 许多 意见 和 建议 ， 
修订 了 一 些 代码 的 变量 、 类 、 方 法 名 称 ， 以 更 加 符合 自然 语言 ， 删 除了 
部 分 有 争议 的 内 容 ( 如 单 例 模 式 的 垃圾 回收 问题 》; 修改 了 一 些 第 用 的 
名 词 ， 确 保 与 编程 人 员 的 习惯 相 匹 配 。 和 希望 通过 这 些 改进 ， 给 读者 提供 
一 个 更 完美 的 设计 模式 盛宴 ， 欢 补 上 一 版 中 的 诸多 不 足 。 














第 2 版 第 38 半 中 新 增 了 4 种 新 的 设计 模式 : 对 象 池 模式 、 雇 工 模式 、 
黑板 模式 、 空 指针 模式 。 这 些 模式 是 我 们 在 实际 工作 中 经 常 遇 到 ， 或 者 
在 开源 代码 时 党 看 到 的 ， 但 是 我 们 却 没有 升级 到 “ 模式 ”这 一 理性 高 度 。 
特别 是 像 空 指针 模式 ， 我 们 在 编码 中 经 常会 遇 到 空 值 判断 问题 ， 但 我 们 
没有 去 想 一 想 是 人 否 可 以 有 更 好 的 方式 解决 。 第 2 版 对 空 指 针 模 式 进行 了 
讲解 ， 虽 然 简单 ， 但 相信 对 你 提升 编码 质量 有 很 大 的 帮助 。 











本 书 的 特色 


简单 、 通 俗 、 易 懂 ， 但 又 不 肤浅 ， 这 是 本 书 的 最 大 特色 。 自己 看 
过 的 技术 书 还 算 比 较 多 ， 很 痛恨 那 种 大 块头 的 巨 兰 ， 搁 家 里 当 枕 头 都 沉 
得 太 便 。 如 果 要 是 再 星 深 难 懂 点 ， 那 根本 没 法 看 ， 看 起 来 实在 是 太 累 。 
设计 模式 原本 就 是 理论 性 的 知识 ， 讲 解 的 难度 比较 大 ， 但 我 相信 这 本 书 
能 够 把 你 对 设计 模 陈 的 八 惧 一 扫 而 光 。 不 信 ? 挑 几 页 先 看 看 ! 











我 的 理念 是 : 像 看 小 说 一 样 阅读 本 书 。 我 尽量 用 浅显 通俗 的 语言 
讲解 ， 尺 量 让 你 有 继续 看 下 去 的 欲望 ， 尺 量 努 力 让 你 有 兴趣 进入 设计 模 
式 的 世界 ， 兴 趣 是 第 一 老师 咏 ! 虽然 我 尽量 让 这 本 书 浅 显 、 通 俗 、 易 
懂 ， 但 并 不 代表 我 的 讲解 就 很 肤浅 。 每 个 设计 模式 讲解 完毕 之 后 ， 我 都 
附加 了 两 个 非常 精华 的 部 分 :设计 模式 扩展 和 最 佳 实践 ， 这 是 俺 压 箱底 
的 技能 了 ， 为 了 博 君 一 看 ， 没 招 了 ， 拌 出 来 吧 ! 尤为 值得 一 提 的 是 ， 本 
书 还 有 设计 模式 PK 和 混 编 设 计 模 式 两 部 分 内 容 教 你 如 何 自如 地 去 运用 
这 些 设计 模式 ， 这 是 当前 所 有 设计 模式 类 的 图 书 都 不 具备 的 ， 连 最 权威 
的 那 本 书 也 不 例外 。 

















我 很 讨厌 技术 文章 中 夹杂 着 的 那些 轮 涩 难 懂 的 文字 ， 特 别 是 一 堆 又 
一 扒 的 名 词 扒 砌 ， 让 人 看 着 就 反胃 。 但 是 为 了 学 习 技 术 ， 为 了 生存 ， 还 
征 必 须 看 下 去 。 国 内 的 技术 文 要 ， 基 本 上 都 是 板 着 一 副 冷 面孔 讲 技术 ， 
为 什么 要 把 技术 弄 得 这 么 生 便 呢 ? 技 术 也 有 它 幽 默 、 有 柔情 的 一 面 ， 只 是 








被 我 们 的 “ 孔 夫子 们 ” 掩 六 了 ， 能 用 萄 个、 白菜 这 种 寻 第 人 都 亢 悉 的 知识 
来 讲解 原子 弹 理论 的 人 ， 那 是 牛人 ， 我 佩服 这 样 的 人 。 记 住 ， 用 一 堆 名 
词 把 你 忽悠 尝 的 人 很 可 能 什么 都 不 异 ! 


本 书 想 告 诉 你 的 是 ， 技 术 也 可 以 很 有 乐趣 ， 也 可 以 让 你 不 用 皱 着 慎 
头 思 考 ， 等 得 你 的 只 是 静 静 地 看 ， 慢 慢 地 思考 ， 本 书 的 内 容 会 润 物 细 无 
声 地 融入 你 的 思维 中 。 


本 书面 癌 的 读者 





热爱 技术 并 且 讨 厌 梧 燥 乏 味 技术 文章 的 读者 都 可 以 看 本 书 ; 


你 是 程序 员 ， 没 问题 ， 本 书 能 够 让 你 写 出 更 加 高 效 、 优 雅 的 代 


你 是 架构 师 ， 那 更 好 ， 设 计 模 式 可 让 你 设计 出 健壮 、 稳 定 、 高 效 
的 系统 ， 并 且 自 动 地 预防 未 来 业务 变化 可 能 对 系统 带 来 的 影响 ; 


你 是 项 目 经 理 ， 也 OK， 设 计 模 式 可 以 让 你 的 工期 大 大 缩短 ， 让 你 
的 项 目 团队 成 员 快 速 地 理解 你 的 意图 ， 最 终 的 成 果 就 是 优质 的 项 目 ; 高 
可 靠 性 、 高 稳定 性 、 高 效率 和 低 维护 成 本 。 


如 何 阅 读本 书 


首先 声明 ， 本 书 中 所 有 的 例子 都 是 用 Java 语 言 来 实现 的 ， 但 是 你 可 
以 随手 翻番 看， 基本 上 能 保证 每 三 条 语句 一 个 注释 ， 可 以 说 是 在 用 咀 们 
的 母语 讲解 设计 模式 。 即 使 你 不 懂 Java 语 言 ， 也 没有 关系 ， 只 要 知道 在 
Java 中 双 斜 杠 (//) 代表 注释 就 足够 了， 况且 Java 如 此 强大 和 盛行 ， 多 了 
解 一 点 没有 坏处 。 类 图 看 不 懂 ? 没关系 ， 不 影响 你 理解 设计 模式 ， 多 看 
看 束 懂 了 ! 





如 果 你 还 没有 编程 经 验 ， 我 建议 你 把 它 当 做 小 说 来 看 ， 人 懂行 的 看 
门道 ， 不 懂行 的 看 热 间 ， 这 里 的 热 亲 足够 多 ， 够 你 看 一 二 的 了 。 你 现在 
能 看 懂 多 少 是 多 少 ， 不 懂 没 有 关系 ， 你 要 知道 ， 经 验 不 是 像 长 青春 着 一 
样 ， 说 长 就 长 出 来 了 ， 它 是 需要 时 间 积 累 的 ， 需 要 你 用 心 去 感受 ， 然 后 
才能 明白 为 什么 要 如 此 设计 。 











如 果 你 已 经 对 编程 有 感觉 了 (至少 两 年 开发 经 验 ) ， 我 相信 你 都 能 
看 懂 ， 但 能 “ 懂 ” 到 什么 程度 ， 就 很 难说 了 ， 看 你 的 水 平 了 。 但 是 ， 我 可 
以 保证 ， 这 里 的 设计 模式 都 是 你 能 看 懂 的 ， 没 有 你 看 不 懂 的 ! 我 建议 你 
通读 这 本 书 ， 然 后 挑 门 你 最 得 意 的 编程 语言 ， 动 手写 吧 ! 给 上 自己 制定 一 
个 计划 ， 每 天 编写 一 段 代 码 ， 不 需要 太 多 ，200 行 足够 ， 时 不 时 地 把 设 
计 模 式 融 入 你 的 代码 中 。 甫 管 是 什么 代码 ， 比 如 你 想 编写 一 个 识别 美女 
图 片 的 程序 ， 好 呀 ， 抓 紧 时 间 去 写 吧 ， 写 好 了 就 不 用 到 处 看 美女 了 ， 程 














序 一 跑 就 把 网 上 的 美女 图 片 都 抓 过 来 了 ， 牛 呀 〈 记 住 ， 程 序 写 好 了 要 分 
享 给 我 ) 。 看 吧 ， 坚 持 下 去 ， 一 年 以 后 你 再 跟 你 的 同 侨 比 较 一 下 ， 那 差 
距 肯 定 不 是 一 般 的 大 。 


如 果 你 是 资深 工程 师 、 架 构 师 、 技 术 顾问 等 高 等 级 的 技术 人 员 ， 那 
告诉 你 ， 你 找 对 这 本 书 J 。 系 统 架构 没有 思路 ? 没有 问题 ， 看 看 扩 
展 部 分 ， 它 会 开阔 你 的 思路 。 系 统 的 维护 成 本 大 局 不 下 ? 看 看 本 书 ， 设 
计 模 式 也 许 能 帮 你 省 点 银子 。 开 发 资源 无 法 保证 ? 设计 模式 能 让 你 用 有 
限 的 资源 《〈 软 硬件 资源 和 人 力 资 源 ) 设计 出 一 个 优秀 的 系统 。 项 目 质量 
参 关 不 齐 ， 缺 陷 一 大 堆 ? 多 用 设计 模式 ， 它 会 给 你 意 想 不 到 的 效果 。 给 
人 讲课 没有 和 勾 材 ? 没 问 题 ， 本 书 中 的 聚 材 足 以 让 你 局 得 阵 阵 掌声 ! 








编程 是 一 门 艺 术 活 ， 我 有 一 个 同事 ， 能 把 类 图 画 成 一 个 小 乌龟 的 形 
状 ， 天才 呀 ! 作为 一 位 技术 人 员 ， 最 基本 的 品质 就 是 诚实 , “知之 为 知 
之 ， 不 知 为 不 知 ， 是 知 也 ”， 自 己 不 懂 没 有 关系 ， 去 学 ， 学 无 止境 ， 但 
是 千 万 不 要 贪 多 ， 这 抓 一 点 ， 那 挖 一 点 ， 好 像 什 么 都 懂 ， 其 实 什 么 都 不 
懂 。 中 国 一 直 推 党 复合 型 人 才 ， 我 不 是 很 赞成 ， 因 为 这 对 年 轻 人 来 说 是 
一 个 误导 。 先 精 一 项 技术 ， 然 后 再 发 散 学 习 ， 先 点 后 面 才 是 正道 。 











记得 《武林 外 传 》 中 有 这 样 一 段 对 话 : 


刑 捕 头 : 手中 无 妨 ， 心 中 有 思 。 





老 日 : 错 了 ， 最 局 境界 是 手中 无 妨 ， 心 中 也 无 刀 。 








体验 一 下 吧 ， 我 们 的 设计 模式 吏 是 一 把 刀 ， 极 致 的 境界 就 是 心中 无 
设计 模式 ， 代 码 亦 无 设计 模式 一 一 设计 模式 随处 可 见 ， 俯 拾 缘 是 ， 已 经 
融入 软件 设计 的 灵魂 中 ， 这 才 是 高 手中 的 高 手 ， 简 称 高 高 手 。 

















哦 ， 最 最 重要 的 筷 记 说 了 ， 请 把 附录 中 的 “23 种 设计 模式 附 图 ? 撕 下 
来 ， 贴 在 你 的 办 公 昌 前 ， 时 不 时 地 看 看 ， 也 让 老板 看 看 ， 咀 是 多 么 地 用 








人心 ! 


关于 作 洗 


乍 一 看 ， 书 名 和 内 容貌 似 不 相符 呀 ， 其 实 不 然 ! 





在 我 们 的 种 规 思 维 中 , “ 禅 ?应 该 是 很 高 深 的 东西 ， 只 可 意 会 ， 不 可 
言传 。 没 错 ， 禅 宗 也 是 如 此 说 。 禅 是 得 道 者 的 “ 悟 ?， 征 不 能 用 言语 来 表 
达 的 ， 但 是 得 道 者 为 了 能 让 更 多 的 人 “ 悟 *"， 束 必须 用 最 容易 让 人 理解 的 
文字 把 自己 的 体会 表达 出 来 。 本 书 的 “ 禅 ? 是 作者 对 设计 模式 的 “ 情 ?， 本 
书 的 “ 形 * 就 是 你 现在 看 到 的 这 些 极其 简单 、 通 俗 、 吻 懂 的 文字 。 

















至 此 ， 大 家 应 该 不 会 再 对 书 名 有 疑虑 了 吧 ， 咖 吗 。 


致谢 








本 书 第 1 版 的 写作 耗 时 7 个 月 ， 第 2 版 的 更 新 又 化 了 4 个 月 ， 可 以 说 是 
榨 干 了 海 绢 里 所 有 的 水 一 一 基本 上 能 用 的 时 间 都 用 上 了 。 在 公交 车 上 打 
腹 稿 ， 干 过 ! 在 马桶 上 得 资料 ， 干 过 ! 在 睡梦 中 思考 案例 ， 也 有 过 ! 惑 
差 没 有 走火 入 麻 了 ! 





首先 ， 感 谢 杨 福 川 编辑 ， 没 有 他 的 芒 眼 ， 这 本 书 不 可 能 出 版 。 其 
次 ， 感 谢 妻 子 和 儿子 ， 每 天 下 班 回 到 家 ， 一 按 门 铃 ， 儿 子 就 在 里 面 
叫 : “我 来 开门 ， 我 来 开门 。” 儿 子 三 岁 ， 太 调皮 了 ， 他 不 睡觉 我 基本 上 
征 不 能 开 与 的 ， 我 一 旦 开始 写 东西 ， 他 惑 跑 过 来 问 :“ 和 多 各， 你 在 干 什 
么 蚜 ?”， 紧 接着 下 一 句 就 是 “爸爸 ， 你 障 我 玩 ?”， 基 本 都 是 拿 我 当 玩 具 ， 
别 的 小 朋友 都 是 把 父 杀 当 马 骑 ， 他 却 不 ， 他 把 我 当 摩托 车 骑 ， 还 要 加 油 
门 ， 发 动 .…… 小 家 伙 脚 太 重 了 ， 再 骑 摩 托 ， 非 被 他 踩 死 不 可 ! 














还 要 感谢 我 的 朋友 王 怠 ， 周 末 只 要 小 家 伙 在 家 ， 我 只 有 找 地 方 写 书 
的 份 儿 ， 王 怠 非 党 爽快 地 把 钥匙 给 我 ， 让 我 有 一 个 安静 的 地 方 写 书 。 一 
个 人 沉浸 在 目 己 喜欢 的 世界 里 也 是 一 件 非 常 幸福 的 事 。 


当然 ， 还 要 感谢 JavaEye 上 所 有 顶 帖 的 网 友 ， 没 有 你 们 的 支持 我 就 
没有 写作 的 动力 ， 就 像 硕 腊 神 话 中 的 巨人 安泰 失去 了 大 地 的 力量 一 样 ， 
是 你 们 的 回帖 让 我 党 得 不 孤单 ， 让 我 知道 我 不 是 一 个 人 在 战斗 ! 








最 后 ， 再 次 对 本 书 中 可 能 出 现 的 错误 表示 歉意 ， 真 诚 地 接受 大 家 下 
炸 ! 如 果 你 在 阅读 本 书 时 发 现 错误 或 有 问题 想 讨 论 ， 请 发 邮件 给 我 。 
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第 一 部 分 “大 旗 不 挥 ， 谁 到 冲锋 
一 一 6 大 设计 原则 全 新 解读 


单一 职责 原则 
里 氏 蔡 换 原 则 
依赖 倒置 原则 
接口 隅 离 原 则 
迪 米 特 法 则 
开 闭 原则 








第 1 章 ”单一 职责 原则 


1.1 我 是 “ 牛 ” 基 ， 我 可 以 担任 多 职 吗 


单一 职责 原则 的 英文 名 称 是 Single Responsibility Principle， 简 称 是 
SRP。 这 个 设计 原则 备 受 和 争议， 只 要 你 想 和 别人 争执 、 慌 气 或 者 是 吵 
架 ， 这 个 原则 是 屡试不爽 的 。 如 果 你 是 老大 ， 看 到 一 个 接口 或 类 是 这 样 
或 那样 设计 的 ， 你 就 问 一 句 :“ 你 设计 的 类 符合 SRP 原 则 吗 ?” 保 准 对 方 
立马 “萎缩 ? 掉 ， 而 且 还 一 脸 肢 拜 地 看 着 你 ， 心 想 :“ 老 大 确实 英明 ”。 这 
个 原则 存在 争议 之 处 在 哪里 呢 ? 就 是 对 职责 的 定义 ， 什 么 是 类 的 职责 ， 
以 及 怎么 划分 类 的 职责 。 我 们 先 举 个 例子 来 说 明 什 么 是 单一 职责 原则 。 

















只 要 做 过 项 目 ， 肯 定 要 接触 到 用 户 、 机 构 、 角 色 管 理 这 些 模块 ， 基 

用 的 都 是 RBAC 模 型 (Role-Based Access Control， 基 于 角色 的 访 
问 控制 ， 通 过 分 配 和 取消 角色 来 完成 用 户 权限 的 授予 和 取消 ， 使 动作 主 
体 ( 用 户 ) 与 资源 的 行为 《权限 ) 分 离 ) ， 确 实 是 一 个 很 好 的 解决 办 
法 。 我 们 这 里 要 讲 的 是 用 户 管理 、 修 改 用 户 的 信息 、 增 加 机 构 (一 个 人 
属于 多 个 机 构 ) 、 增 加 角色 等 ， 用 户 有 这 么 多 的 信息 和 行为 要 维护 ， 我 
们 就 把 这 些 写 到 一 个 接口 中 ， 都 是 用 户 管理 类 嘛 ， 我 们 先 来 看 它 的 类 
图 ， 如 图 1-1 所 示 。 





<<interface>> 
IUserlnfo 
ee 
Hvoid setUserID(String userID) 
+Strng getUserID() 
+vold setPassword(Strng password) 
+Strng getPassword() 


+vold setUserName(String userName) 


HStrng getUserName() 

+boolean changePassword(Strng oldPassword) 
+boolean deleteUser() 

+vold mapUser() 

+boolean addOrg( nt orgID) 

+boolean addRole(int roleID) 





Userlnfo 
ES 
[: 


图 1-1 用 户 信息 维护 类 图 





太 Easy 的 类 图 了 ， 我 相信 ， 即 使 是 一 个 初级 的 程序 员 也 可 以 看 出 这 
个 接口 设计 得 有 问题 ， 用 户 的 属性 和 用 户 的 行为 没有 分 开 ， 这 是 一 个 严 
重 的 错误 ! 这 个 接口 确实 设计 得 一 团 糟 ， 应 该 把 用 户 的 信息 抽取 成 一 个 
BO (Business Object， 业 务 对 象 ) ， 把 行为 抽取 成 一 个 Biz (Business 
Logic， 业 务 逻 辑 ) ， 按 照 这 个 思路 对 类 图 进行 修正 ， 如 图 1-2 所 示 。 


<<nterface>> =<mterface>> 
IUserBO IUserBiz 


tvoid setUserID(Strmg userID) tboolean changePassword(...) 

tString getUserID(O) +boolean deleteUser(IUserBO userBO) 

tHvold setPassword(String password) +void mapUser(IUserBO userBO) 

tStrmg getPassword() tboolean addOrg(TUserBO userBO, mt orgID) 


+void setUserName(String userName) Hboolean addRole(IUserBO userBO, int roleID) 
+String getUserName() : 


<<Interface>> 
IUserlinfo 











负责 用 户 的 行为 


负责 用 户 的 属性 





图 1-2 职 贡 划分 后 的 类 图 


重新 拆 封 成 两 个 接口 ，IUserBO 负 责 用 户 的 属性 ， 简 单 地 说 ， 
IUserBO 的 职员 就 是 收集 和 反馈 用 户 的 属性 信息 ; IUserBiz 负 责 用 户 的 
行为 ， 完 成 用 户 信息 的 维护 和 变更 。 各 位 可 能 要 说 了 ， 这 个 与 我 实际 工 
作 中 用 到 的 User 类 还 是 有 差别 的 呀 ! 别 着 急 ， 我 们 先 来 看 一 看 分 拆 成 两 
个 接口 怎么 使 用 。OK， 我 们 现在 是 面向 接口 编程 ， 所 以 产生 了 这 个 
UserInfo 对 象 之 后 ， 当 然 可 以 把 它 当 IUserBO 接 口 使 用 。 也 可 以 当 
IUserBiz 接 口 使 用 ， 这 要 看 你 在 什么 地 方 使 用 了 。 要 获得 用 户 信息 ， 就 
当 是 IUserBO 的 实现 类 ; 要 是 希望 维护 用 户 的 信息 ， 就 把 它 当 作 
IUserBiz 的 实现 类 就 成 了 ， 如 代码 清单 1-1 所 示 。 














代码 清单 1-1 分 清 职责 后 的 代码 示例 


IUSerInfo USserInfo = new UserInfol( ) ， 
// 我 要 赋值 了 ， 我 就 认为 它 是 一 个 纯粹 的 BO 
IUSerBO userBO = (IUSerBOo)userInfo ， 
userBO.setPassword("abc"); 

// 我 要 执行 动作 了 ， 我 就 认为 是 一 个 业务 逻辑 类 
IUserBiz userBiz = (IUserBiz)userIinfo; 
userBiz.deleteUser(); 











确实 可 以 如 此 ， 问 题 也 解决 了 ， 但 是 我 们 来 分 析 一 下 刚才 的 动作 ， 
为 什么 要 把 一 个 接口 拆 分 成 两 个 呢 ? 其 实 ， 在 实际 的 使 用 中 ， 我 们 更 倾 
向 于 使 用 两 个 不 同 的 类 或 接口 : 一 个 是 IUserBO， 一 个 是 IUserBiz， 类 
图 如 图 1-3 所 示 。 


<<Interface>> <<interface>> 
IUserBO IUserBiz 









图 1-3 项 目 中 经 癌 采 用 的 SRP 类 图 


以 上 我 们 把 一 个 接口 拆 分 成 两 个 接口 的 动作 ， 惑 是 依赖 了 单一 职责 
原则 ， 那 什么 是 单一 职责 原则 呢 ? 单一 职 贡 原则 的 定义 是 : 应 该 有 且 仅 








有 一 个 原因 引起 类 的 变更 。 


1.2 绝 杀 技 ， 打 破 你 的 传统 思维 





解释 到 这 里 ， 估 计 你 已 经 很 不 局 了 ,“ 切 ! 这 么 简单 的 东西 还 要 
讲 ? ! ”好 ， 我 们 来 讲 点 复杂 的 。SRP 的 原 话 解释 是 : 


There should never be more than one reason for a class to change. 








这 人 句 话 初中 生 都 能 看 懂 ， 不 多 说 ， 但 是 看 懂 是 一 人 码 事 ， 实 施 束 是 为 
外 一 码 事 了 。 上 面 讲 的 例子 很 好 理解 ， 在 实际 项 目 中 大 家 都 已 经 这 么 做 
了 ， 那 我 们 再 来 看 看 下 面 这 个 例子 是 否 好 理解 。 电 话 这 玩意 ， 是 现代 人 
都 离 不 了 ， 电 话 通 话 的 时 候 有 4 个 过 程 发 生 : 拨号 、 通 话 、 回 应 、 挂 
机 ， 那 我 们 写 一 个 接口 ， 其 类 图 如 图 1-4 所 示 。 








<<Interface>> 
IPhone 


+vold dial(Strmg phone Number) 
+vold chat(Object o) 
+vold hangup() 





图 1-4 电话 类 图 


我 不 是 有 意 要 冒犯 IPhone 的 ， 同 名 纯 属 巧合 ， 我 们 来 看 一 个 这 个 过 
程 的 代码 ， 如 代码 清单 1-2 所 示 。 


代码 清单 1-2 电话 过 程 


public interface IPhone { 
// 拨 通电 话 
public void dial(String phoneNumber ) ; 
// 通 话 
public void chat(Object 0o); 
// 通 话 完毕 ， 挂 电话 
public void hangup(); 





实现 类 也 比较 简单 ， 我 就 不 再 写 了 ， 大 家 看 看 这 个 接口 有 没有 问 
题 ? 我 相信 大 部 分 的 读者 都 会 说 这 个 没有 问题 呀 ， 以 前 我 就 是 这 么 做 的 
了 呀 ， 茶 茶 书 上 也 是 这 么 写 的 呀 ， 还 有 什么 什么 的 源码 也 是 这 么 写 的 ! 是 
的 ， 这 个 接口 接近 于 完美 ， 看 清楚 了 ， 是 “接近 ”! 单一 职责 原则 要 求 一 
个 接口 或 类 只 有 一 个 原因 引起 变化 ， 也 就 是 一 个 接口 或 类 只 有 一 个 职 
责 ， 它 就 负责 一 件 事情 ， 看 看 上 面 的 接口 只 负责 一 件 事情 吗 ? 是 只 有 一 
个 原因 引起 变化 吗 ? 好 像 不 是 ! 























IPhone 这 个 接口 可 不 是 只 有 一 个 职责 ， 它 包含 了 两 个 职责 : 一 个 是 
协议 管理 ， 一 个 是 数据 传送 。dial0 和 hangupO 两 个 方法 实现 的 是 协议 管 
理 ， 分 别 负责 拨号 接 通 和 挂机 ，chatO 实 现 的 是 数据 的 传送 ， 把 我 们 说 
的 话 转 换 成 模拟 信号 或 数字 信和 号 传递 到 对 方 ， 然 后 再 把 对 方 传递 过 来 的 
信号 还 原 成 我 们 听 得 懂 的 语言 。 我 们 可 以 这 样 考虑 这 个 问题 ， 协 议 接 通 
的 变化 会 引起 这 个 接口 或 实现 类 的 变化 吗 ? 会 的 ! 那 数据 传送 ( 想 想 





看 ， 电 话 不 仅仅 可 以 通话 ， 还 可 以 上 网 ) 的 变化 会 引起 这 个 接口 或 实现 
类 的 变化 吗 ? 会 的 ! 那 就 很 简单 了 ， 这 里 有 两 个 原因 都 引起 了 类 的 变 

化 。 这 两 个 职责 会 相互 影响 吗 ? 电话 拨号 ， 我 只 要 能 接 通 就 成 ， 十 管 是 
电信 的 还 是 网 通 的 协议 ， 电 话 连 接 后 还 关心 传递 的 是 什么 数据 吗 ? 通过 








这 样 的 分 析 ， 我 们 发 现 类 图 上 的 IPhone 接 口 包 含 了 两 个 职责 ， 而 且 这 两 
个 职 贡 的 变化 不 相互 影响 ， 那 就 考虑 拆 分 成 两 个 接口 ， 其 类 图 如 图 1-5 
所 示 。 


<<interface>> <<interface>> 
lIConnectionManager IDataTransfer 


[=e 
tvoid dial(String phone Number) +DataTransfer(IConnection Manager cm) 
Hvoid hangup() 

















ConnectionManager DataTransfer 
| c= 
= | 


图 1-5 职 贡 分 明 的 电话 类 图 


<<Interface>> 
IConnectionM anager le 
一 
+void dial(String phoneNumber) 

+void hangup() 


<<Interface>> 
IDataTransfer 


[| 
+DataTransfer(IConnection Manager cm) 








图 1-6 简洁 清晰 、 职 责 分 明 的 电话 类 图 


这 个 类 图 看 上 去 有 点 复杂 了 ， 完 全 满足 了 单一 职责 原则 的 要 求 ， 每 
个 接口 职责 分 明 ， 结 构 清晰 ， 但 是 我 相信 你 在 设计 的 时 候 肯定 不 会 采用 
ee 
块 才能 使 用 。 一 种 强 耦 合 关 系 ， 你 和 我 都 有 共同 的 生命 期 ， 这 样 
的 强 耦 合 关 系 还 不 如 使 用 接口 实现 的 方式 呢 ， 而 且 还 增加 了 类 的 复杂 
性 ， 多 了 两 个 类 。 经 过 这 样 的 思考 后 ， 我 们 再 修改 一 下 类 图 ， 如 图 1-6 
所 示 。 








这 样 的 设计 才 是 完美 的 ， 一 个 类 实现 了 两 个 接口 ， 把 两 个 职 贡 融合 
在 一 个 类 中 。 你 会 觉得 这 个 Phone 有 两 个 原因 引起 变化 了 呀 ， 是 的 ， 但 
是 别 态 记 了 我 们 是 面向 接口 编程 ， 我 们 对 外 公布 的 是 接口 而 不 是 实现 
类 。 而 且 ， 如 果真 要 实现 类 的 单一 职 贡 ， 这 个 残 必须 使 用 上 面 的 组 合 模 
式 了 ， 这 会 引起 类 间 耦 合 过 重 、 类 的 数量 增加 等 问题 ， 人 为 地 增加 了 设 
计 的 复杂 性 。 














通过 上 面 的 例子 ， 我 们 来 总 结 一 下 单一 职责 原则 有 什么 好 处 : 
e 类 的 复杂 性 降低 ， 实 现 什么 职责 都 有 清晰 明确 的 定义 ; 

e 可 该 性 提高 ， 复 杂 性 降低 ， 那 当然 可 读 性 提高 了 

e 可 维护 性 提高 ， 可 读 性 提高 ， 那 当然 更 容易 维护 了 ; 


e 变更 引起 的 风险 降低 ， 变 更 是 必 不 可 少 的 ， 如 果 接 口 的 单一 职 贡 
做 得 好 ， 一 个 接口 修改 只 对 相应 的 实现 类 有 影响 ， 对 其 他 的 接口 无 影 
响 ， 这 对 系统 的 扩展 性 、 维 护 性 都 有 非常 大 的 帮助 。 











看 过 电话 这 个 例子 后 ， 是 不 是 想 反 思 一 下 了 ， 我 以 前 的 设计 是 不 是 
有 点 问题 了 ? 不 ， 不 是 的 ， 不 要 怀疑 自己 的 技术 能 力 ， 单 一 职责 原则 最 
难 划 分 的 就 是 职责 。 一 个 职责 一 个 接口 ， 但 问题 是 “职责 ?没有 一 个 量化 
的 标准 ， 一 个 类 到 底 要 负责 那些 职责 ? 这 些 职责 该 怎么 细 化 ? 细 化 后 是 
侍 部 要 有 一 个 接口 或 类 ?这 些 都 需要 从 实际 的 项 目 去 考虑 ， 从 功能 上 来 
说 ， 定 义 一 个 IPhone 接 口 也 没有 错 ， 实 现 了 电话 的 功能 ， 而 且 设 计 还 很 
简单 ， 仅 仅 一 个 接口 一 个 实现 类 ， 实 际 的 项 目 我 想 大 家 都 会 这 么 设计 。 
项 目 要 考虑 可 变 因素 和 不 可 变 因 系 ， 以 及 相关 的 收益 成 本 比率 ， 因 此 设 
计 一 个 IPhone 接 口 也 可 能 是 没有 错 的 。 但 是 ， 如 果 纯 从 “学 究 ” 理 论 上 分 
析 就 有 问题 了 ， 有 两 个 可 以 变化 的 原因 放 到 了 一 个 接口 中 ， 这 惑 为 以 后 
的 变化 高 来 了 风险 。 如 果 以 后 模拟 电话 升级 到 数字 电话 ， 我 们 提供 的 接 
口 IPhone 是 不 是 要 修改 了 ? 接口 修改 对 其 他 的 Invoker 类 是 不 是 有 很 大 时 
































~ 








NS 


啊 ? 





注意 单一 职责 原则 提出 了 一 个 编写 程序 的 标准 ， 用 “职责 ?或 “ 变 
化 原因 ”来 衡量 接口 或 类 设计 得 是 否 优 民 ， 但 是 “职责 * 和 “变化 原因 ”都 
古 不 可 撤 量 的 ， 因 项 目 而 寞 ， 因 环境 而 腊 。 











1.3 我 单纯 ， 所 以 我 快乐 











对 于 接口 ， 我 们 在 设计 的 时 候 一 定 要 做 到 单一 ， 但 是 对 于 实现 类 束 
再 要 多 方面 考虑 了 。 生 搬 硬 套 单一 职责 原则 会 引起 类 的 剧 增 ， 给 维护 带 
来 非常 多 的 及 烦 ， 而 且 过 分 细 分 类 的 职责 也 会 人 为 地 增加 系统 的 复杂 
性 。 本 来 一 个 类 可 以 实现 的 行为 硬 要 拆 成 两 个 类 ， 然 后 再 使 用 聚合 或 组 
合 的 方式 看 合 在 一 起 ， 人 为 制造 了 系统 的 复杂 性 。 所 以 原则 是 死 的 ， 人 
是 活 的 ， 这 人 句 话 很 有 道理 


单一 职责 原则 很 难 在 项 目 中 得 到 体现 ， 非 常 难 ， 为 什么 ? 在 国内 ， 
技术 人 员 的 地 位 和 话语 权 都 比较 低 ， 因 此 在 项 目 中 需要 考虑 环境 ， 考 虑 
工作 量 ， 考 虑 人 员 的 技术 水 平 ， 考 虑 硬件 的 资源 情况 ， 等 等 ， 最 终 妥协 
的 结果 是 经 常 违背 单一 职责 原则 。 而 且 ， 我 们 中 华文 明 就 有 很 多 属于 混 
合 型 的 产物 ， 比 如 筑 子 ， 我 们 可 以 把 筷子 当做 刀 来 使 用 ， 分 割 食物 ; 
可 以 当 又 使 用 ， 把 食物 从 盘子 中 移动 到 口中 。 而 在 西方 的 文化 中 ， 刀 就 
是 刀 ， 又 就 是 又 ， 你 去 吃 西餐 的 时 候 这 两 样 肯定 都 是 有 的 ， 刀 就 是 切割 
食物 ， 又 就 是 固定 食物 或 者 移动 食物 ， 分 工 很 明晰 。 这 种 文化 的 差异 很 
难 一 步 改造 过 来 ， 但 是 我 相信 随 着 技术 的 深入 ， 单 一 职责 原则 必然 会 深 
入 到 项 目的 设计 中 ， 而 且 这 个 原则 是 那么 的 简单 ， 简 单 得 不 需要 我 们 更 
加 深入 地 思考 ， 单 从 字面 上 大 家 都 应 该 知道 是 什么 意思 ， 单 一 职责 嘛 ! 




















单一 职责 适用 于 接口 、 类 ， 同 时 也 适用 于 方法 ， 什 么 意思 呢 ? 一 个 
方法 尽 可 能 做 一 件 事情 ， 比 如 一 个 方法 修改 用 户 密 码 ， 不 要 把 这 个 方法 





放 到 “修改 用 户 信 息 ” 方 法 中 ， 这 个 方法 的 颗粒 度 很 粗 ， 比 如 图 1-7 中 所 
示 的 方法 。 


<<interface>> 
IUserManager 


| 
+vold changeUser(IUserBO userBO, Strmg...changeOptions) 





图 1-7 一 个 方法 承担 多 个 职责 


在 IUserManager 中 定义 了 一 个 方法 changeUser， 根 据 传递 的 类 型 不 
同 ， 把 可 变 长 度 参数 changeOptions 修 改 到 userBO 这 个 对 象 上 ， 并 调用 持 
久 层 的 方法 保存 到 数据 库 中 。 在 我 的 项 目 组 中 ， 如 果 有 人 写 了 这 样 一 个 
方法 ， 我 不 管 他 写 了 多 少 程序 ， 花 了 多 少 工夫 ， 一 律 重 写 ! 原因 很 简 
单 : 方法 职责 不 清晰 ， 不 单一 ， 不 要 让 别人 猜测 这 个 方法 可 能 是 用 来 处 
理 什 么 逻辑 的 。 比 较 好 的 设计 如 图 1-8 所 示 。 








通过 类 图 可 知 ， 如 果 要 修改 用 户 名 称 ， 就 调用 changeUserName 方 
法 ; 要 修改 家 庭 地 址 ， 就 调用 changeHomeAddress 方 法 ， 要 修改 单位 电 
话 ， 就 调用 changeOtfficeTel 方 法 。 每 个 方法 的 职责 非常 清晰 明确 ， 不 仅 
开发 简单 ， 而 且 日 后 的 维护 也 非常 容易 ， 大 家 可 以 逐渐 养 成 这 样 的 习 


惯 。 





<<Interface>> 
IUserManager 


+void changeUserName(String newUserName) 
+vold changeHome Address(String newHomeAddress) 
+vold changeOfficeTel(Strmg teINumber) 





图 1-8 一 个 方法 承担 一 个 职责 


所 以 ， 如 果 对 接口 、 类 、 方 法 使 用 了 单一 职责 原则 ， 那 么 快乐 的 就 
不 仅仅 是 你 了 ， 还 有 你 的 项 目 组 成 员 ， 大 家 可 以 轻松 而 又 愉快 地 进行 开 
发 ; 还 有 你 的 老板 ， 减 少 了 因为 变更 引起 的 工作 量 ， 减 少 了 无 谓 的 人 员 
和 资金 消耗 。 当 然 ， 最 快乐 的 也 许 束 是 你 了 ， 因 为 加 官 普 蜗 可 能 等 着 你 
哟 ! 


1.4 最 佳 实践 


阅读 到 这 里 ， 可 能 有 人 会 问 我 ， 你 写 的 是 类 的 设计 原则 吗 ? 你 通 篇 
都 在 说 接口 的 单一 职责 ， 类 的 单一 职责 你 都 违背 了 呀 ! 呵呵 ， 这 个 还 真 
是 的 ， 我 的 本 意 是 想 把 这 个 原则 讲 清楚 ， 类 的 单一 职责 咏 ， 这 个 很 简 
单 ， 但 当 我 回头 写 的 时 候 ， 发 觉 并 不 是 这 么 回 事 ， 翻 看 了 以 前 的 一 些 设 
计 和 代码 ， 基 本 上 拿 得 出 手 的 类 设计 都 是 与 单一 职责 相 违背 的 。 静 下 心 
来 回忆 ， 人 发 觉 每 一 个 类 这 样 设计 都 是 有 原因 的 。 我 查阅 了 Wikipedia、 
OODesign 等 几 个 网 站 ， 专 家 和 我 也 有 类 似 的 经 验 ， 基 本 上 类 的 单一 职 
责 都 用 了 类 似 的 一 句 话 来 说 "This is sometimes hard to see"， 这 句 话 翻译 
过 来 就 是 “这 个 有 时 候 很 难说 ”。 是 的 ， 类 的 单一 职责 确实 受 非常 多 因素 
的 制约 ， 纯 理论 地 来 讲 ， 这 个 原则 是 非常 优秀 的 ， 但 是 现实 有 现实 的 难 
处 ， 你 必须 去 考虑 项 目 工期 、 成 本 、 人 员 技 术 水 平 、 硬 件 情况 、 网 络 情 
况 甚至 有 时 候 还 要 考虑 政府 政策 、 垄 断 协议 等 因素 。 比 如 ，2004 年 我 就 
做 过 一 个 项 目 ， 做 加 密 处 理 的 ， 甲 方 就 甩 过 来 一 句 话 ， 你 什么 都 不 用 
管 ， 调 用 这 个 API 就 可 以 了 ， 不 用 考虑 什么 传输 协议 、 异 常 处 理 、 安 全 
连接 等 。 所以， 我 们 就 直接 使 用 了 JNI 与 加 密 厂 商 提 供 的 API 通 信 ， 什 么 
单一 职员 原则， 根本 就 不 用 考虑 ， 因 为 对 方 不 公布 通信 接口 和 异常 判 

















荐 。 


对 于 单一 职责 原则 ， 我 的 建议 是 接口 一 定 要 做 到 单一 职责 ， 类 的 设 


计 尽量 做 到 只 有 一 个 原因 引起 变化 。 


第 2 章 ” 里 氏 谷 换 原 则 


2.1 爱 恨 纠 多 的 父子 关系 


在 面 问 对象 的 语言 中 ， 继 承 是 必 不 可 少 的 、 非 常 优秀 的 语言 机 制 ， 
它 有 如 下 优点 : 





e 代码 共享 ， 减 少 创建 类 的 工作 量 ， 每 个 子 类 都 拥有 父 类 的 方法 和 
属性 ; 


e 提高 代码 的 重用 性 ; 





e 了 类 可 以 形似 父 类 ， 但 又 寞 于 父 类 ,“ 龙 生 龙 ， 凤 生 凤 ， 老 妃 生 
来 会 打 洞 ”是 说 子 拥有 父 的 “种 ”， “世界 上 没有 两 片 完全 相同 的 叶子 ”是 
各 明子 与 父 的 不 同 ; 





e 提高 代码 的 可 扩展 性 ， 实 现 父 类 的 方法 束 可 以 “为 所 欲 为 * 了 ， 君 
不 见 很 多 开源 框架 的 扩展 接口 都 是 通过 继承 父 类 来 完成 的 ; 





e 提高 产品 或 项 目的 开放 性 。 


目 然 界 的 所 有 事物 都 是 优点 和 缺点 并 存 的 ， 即 使 是 鸡 重 ， 有 时 候 也 
能 挑 出 骨头 来 ， 继 承 的 缺点 如 下 : 


e 继承 是 侵入 性 的 。 只 要 继承 ， 束 必须 拥有 父 类 的 所 有 属性 和 方 
法 ; 


e 降低 代码 的 灵活 性 。 子 类 必须 拥有 父 类 的 属性 和 方法 ， 让 子 类 上 自 
由 的 世界 中 多 了 些 约束 ; 


e 增强 了 耦合 性 。 当 父 类 的 常量 、 变 量 和 方法 被 修改 时 ， 需 要 考虑 
子 类 的 修改 ， 而 且 在 缺乏 规范 的 环境 下 ， 这 种 修改 可 能 珊 来 非常 糟 料 的 
结果 一 一 大 段 的 代码 需要 重 构 。 


Java 使 用 extends 关 键 字 来 实现 继承 ， 它 采用 了 单一 继承 的 规则 ， 
C++ 则 采用 了 多 重 继承 的 规则 ， 一 个 子 类 可 以 继承 多 个 父 类 。 从 整体 上 
来 看 ， 利 大 于 次 ， 怎 么 才能 让 “不 ”的 因素 发 挥 最 大 的 作用 ， 同 时 减 
少 “ 浆 ” 融 来 的 麻烦 呢 ?” 解 决 方案 是 引入 里 氏 蔡 换 原则 Liskov 
Substitution Principle，LSP) ， 什 么 是 里 氏 蔡 换 原 则 昵 ? 它 有 两 种 定 
义 : 








e 第 一 种 定义 ， 也 是 最 正宗 的 定义 : If for each object ol of type S 
there is an object 02 of type T such that for all programs P defined in terms of 
T,the behavior of P is unchanged when ol is substituted for 02 then S isa 
subtype of T.〈 如 有 果 对 每 一 个 类 型 为 的 对 象 01， 都 有 类 型 为 T 的 对 象 
02， 使 得 以 T 定 义 的 所 有 程序 P 在 所 有 的 对 象 o1 都 代 换 成 0o2 时 ， 程 序 P 的 
行为 没有 发 生变 化 ， 那 么 类 型 S 是 类 型 T 的 子 类 型 。) 








A 一 


e 第 二 种 定义 : Functions that use pointers or references to base classes 
must be able to use objects of derived classes without knowing it. (所 有 引 


用 基 类 的 地 方 必须 能 透明 地 使 用 其 子 类 的 对 象 。) 








第 二 个 定义 是 最 清晰 明确 的 ， 通 俗 点 讲 ， 只 要 父 类 能 出 现 的 地 方 子 

类 就 可 以 出 现 ， 而 且 蔡 换 为 子 类 也 不 会 产生 任何 错误 或 异常 ， 使 用 者 可 

能 根本 就 不 需要 知道 是 父 类 还 是 子 类 。 但 是 ， 反 过 来 就 不 行 了 ， 有 子 类 
出 现 的 地 方 ， 父 类 未 必 束 能 适应 。 











2.2 纠纷 不 断 ， 规 则 压制 


里 氏 蔡 换 原 则 为 良好 的 继承 定义 了 一 个 规范 ， 一 句 简 单 的 定义 包含 
了 4 层 含义 。 


1. 子 类 必须 完全 实现 父 类 的 方法 


我 们 在 做 系统 设计 时 ， 经 常会 定义 一 个 接口 或 抽象 类 ， 然 后 编码 实 
现 ， 调 用 类 则 直接 传 入 接口 或 抽象 类 ， 其 实 这 里 已 经 使 用 了 里 氏 玲 换 原 


则 。 我 们 举 个 例子 来 说 明 这 个 原则 ， 大 家 都 打 过 CS 吧 ， 非 党 经典 的 FPS 
类 游戏 ， 我 们 来 摘 述 一 下 里 面 用 到 的 枪 ， 类 图 如 图 2-1 所 示 。 


Client 










-AbstractGun gun 
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+void setGun(AbstractGun _gun) +void shoot() 


+void kilEnemy() 








手相 入 


图 2-1 CS 游戏 中 的 枪 文 类 图 


枪 的 主要 职责 是 射击 ， 如 何 射击 在 各 个 具体 的 子 类 中 定义 ， 手 枪 是 
单 发 射程 比较 近 ， 步 枪 威力 大 射程 远 ， 机 枪 用 于 扫射 。 在 士兵 类 中 定义 
了 一 个 方法 killEnemy， 使 用 枪 来 杀 敌 人 ， 有 具体 使 用 什么 枪 来 杀 敌 人 ， 调 
用 的 时 候 才 知道 ，AbstractGun 类 的 源 程序 如 代码 清单 2-1 所 示 。 


代码 清单 2-1 枪支 的 抽象 类 


public abstract class AbstractGun { 
// 枪 用 来 干什么 的 ? 杀 政 ! 


public abstract void shoot(); 


和 手枪、 步枪、 机枪 的 实现 类 如 代码 清单 2-2 所 示 。 


代码 清单 2-2 手枪 、 步 枪 、 机 枪 的 实现 类 


public class Handgun extends AbstractGun { 
// 手 枪 的 特点 是 携带 方便 ， 射 程 短 
@Override 
public void shoot() { 
System.out .println(" 手 枪 射击 ,..")， 
} 


public class Rifle extends AbstractGunt{ 
// 步 枪 的 特点 是 射程 远 ， 威 力 大 
public void shoot(){ 
System.out .println(" 步 枪 射击 ,..")， 
} 


public class MachineGun extends AbstractGunt{ 
public void shoot()t{ 
System.out .printlin(" 机 枪 扫 射 ..."); 
} 














有 了 枪 文 ， 还 要 有 能 够 使 用 这 些 枪支 的 士兵 ， 其 源 程序 如 代码 清单 
2-3 所 示 。 


代码 清单 2-3 士兵 的 实现 类 


public > Soldier { 
// 定 义士 兵 的 枪 文 
_ AbstractGun dun 
// 给 士兵 一 支 枪 
public void setGun(AbstractGun _gun)t{ 
this.gun = _gun; 





} 

public void killEnemy(){ 
System.out.printlin(" 士 兵 开 始 杀 敌人 ..."); 
gun. shoot(); 


定义 士兵 使 用 枪 来 杀 敌 ， 但 是 这 把 枪 是 抽象 的 ， 有 具体 是 手枪 还 
枪 需 要 在 上 战场 前 (也 就 是 场景 中 ) 前 通过 setGun 方 法 确定 。 场 景 类 
Client 的 源 代 码 如 代码 清单 2-4 所 示 。 





代码 清单 2-4 场景 类 


public class Client { 
public static void main(String[|] args) { 
// 产 生 三 毛 这 个 士兵 
Soldier SanMao = new Soldier(); 
// 给 三 毛 一 支 枪 
sanMao.setGun(new Rifle()); 
sanMao.killEnemy( ) ; 





有 人 ， 有 枪 ， 也 有 场景 ， 运 行 结果 如 下 所 示 。 





士兵 开始 杀 敌 人 .… 


步枪 射击 … 


在 这 个 程序 中 ， 我 们 给 三 毛 这 个 士兵 一 把 步枪 ， 然 后 就 开始 杀 敌 
了 。 如 果 三 毛 要 使 用 机 枪 ， 当 然 也 可 以 ， 直 接 把 sanMao.setGun(new 
RifleO) 修 改 为 sanMao.setGun(new MachineGun()) 即 可 ， 在 编写 程序 时 
Solider 士 兵 类 根本 束 不 用 知道 是 哪个 型 写 的 枪 ( 子 类 ) 被 传 入 。 





是 


注意 ”在 类 中 调用 其 他 类 时 务必 要 使 用 父 类 或 接口 ， 如 果 不 能 使 
用 父 类 或 接口 ， 则 说 明 类 的 设计 已 经 违背 了 了 LSP 原则。 





我 们 再 来 想 一 想 ， 如 果 我 们 有 一 个 玩具 手枪 ， 该 如 何 定义 呢 ? 我 们 
先 在 类 图 2-1 上 增加 一 个 类 ToyGun， 然 后 继承 于 AbstractGun 类 ， 修 改 后 
的 类 图 如 图 2-2 所 示 。 
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图 2-2 枪支 类 图 


首先 我 们 想 ， 玩 具 枪 是 不 能 用 来 射击 的 ， 杀 不 死人 的 ， 这 个 不 应 该 
写 在 shoot 方 法 中 。 新 增加 的 ToyGun 的 源 代 码 如 代码 清单 2-5 所 示 。 


代码 清单 2-5 玩具 枪 源 代码 


public class ToyGun extends AbstractGun { 
// 玩 具 枪 是 不 能 射击 的 ， 但 是 编译 器 又 要 求实 现 这 个 方法 ， 怎 么 办 ? 虚构 一 个 顺 ! 
Q@Override 
public void shoot() { 
// 玩 具 枪 不 能 射击 ， 这 个 方法 就 不 实现 了 
} 




















由 于 引入 了 新 的 子 类 ， 场 景 类 中 也 使 用 了 该 类 ，Client 稍 作 修改 ， 
源 代码 如 代码 清单 2-6 所 示 。 


代码 清单 2-6 场景 类 


public class Client { 
public static void main(String[] args) { 
// 产 生 三 毛 这 个 士兵 
Soldier SanMao = new Soldier(); 
sanMao.setGun(new ToyGun()); 
sanMao.killEnemy( ); 


把 玩具 枪 传递 给 三 毛 用 来 杀 敌 ， 代 码 运 行 结果 如 下 所 示 : 


士兵 开始 杀 敌 人 ... 





二 了， 士兵 使 着 玩具 枪 来 杀 敌 人 ， 射 不 出 子弹 呀 ! 如 果 在 CS 游戏 


中 有 这 种 事情 肥 生 ， 那 你 就 等 着 被 人 爆 头 吧 ， 然 后 看 者 自己 姜 惨 地 倒 
地 。 在 这 种 情况 下 ， 我 们 发 现 业 务 调用 类 已 经 出 现 了 问题 ， 正 和 常 的 业务 
逻辑 已 经 不 能 运行 ， 那 怎么 办 ? 好 办 ， 有 两 种 解决 办 法 : 








e 在 Soldier 类 中 增加 instanceof 的 判断 ， 如 果 是 玩具 枪 ， 就 不 用 来 杀 
和 政 人 。 这 个 方法 可 以 解决 问题 ,但 是 你 要 知道 ， 在 程序 中 ， 每 增加 一 个 
类 ， 上 所 有 与 这 个 父 类 有 关系 的 类 都 必须 修改 ， 你 觉得 可 行 吗 ? 如 果 你 的 
产品 出 现 了 这 个 问题 ， 因 为 修正 了 这 样 一 个 Bug， 就 要 求 所 有 与 这 个 父 
类 有 关系 的 类 都 增加 一 个 判断 ， 客 户 非 跳 起 来 跟 你 干 架 不 可 ! 你 还 想 要 
客户 忠诚 于 你 吗 ? 显然 ， 这 个 方案 被 否定 了 。 





e ToyGun 脱 离 继承 ， 建 立 一 个 独立 的 父 类 ， 为 了 实现 代码 复 用 ， 可 
以 与 AbastractGun 建 立 关 联 委 托 关 系 ， 如 图 2-3 所 示 。 
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图 2-3 玩具 枪 与 真实 枪 分 离 的 类 图 


例如 ， 可 以 在 AbstractToy 中 声明 将 声音 、 形 状 都 委托 给 AbstractGun 
处 理 ， 仿 真 枪 嘛 ， 形 状 和 声音 都 要 和 真实 的 枪 一 样 了 ， 然 后 两 个 基 类 下 
的 子 类 自由 延展 ， 互 不 影响 。 





在 Java 的 基础 知识 中 都 会 讲 到 继承 ，Java 的 三 大 特征 呆 ， 封 装 、 继 
承 、 多 态 。 继 承 就 是 告诉 你 拥有 父 类 的 方法 和 属性 ， 然 后 你 就 可 以 重 写 
父 类 的 方法 。 按 照 继承 原则 ， 我 们 上 面 的 玩具 枪 继承 AbstractGun 有 是 绝对 
没有 问题 的 ， 玩 具 枪 也 是 枪 咏 ， 但 是 在 具体 应 用 场景 中 就 要 考虑 下 面 这 
个 问题 了 : 子 类 是 否 能 够 完整 地 实现 父 类 的 业务 ， 否 则 就 会 出 现 像 上 面 


的 拿 检 杀 敌 人 时 却 发 现 是 把 玩具 枪 的 笑话 。 














注意 ”如 果子 类 不 能 完整 地 实现 父 类 的 方法 ， 或 者 父 类 的 某 些 方 
法 在 子 类 中 己 经 发 生 “ 畸 变 ”?， 则 建议 断 开 父子 继承 关系 ， 采 用 依赖 、 聚 
集 、 组 合 等 关系 代 蔡 继承 。 











2. 子 类 可 以 有 自己 的 个 性 





子 类 当然 可 以 有 自己 的 行为 和 外 观 了 ， 也 就 是 方法 和 属性 ， 那 这 里 
为 什么 要 再 提 呢 ? 是 因为 里 氏 蔡 换 原则 可 以 正 着 用 ， 但 是 不 能 反 过 来 
用 。 在 子 类 出 现 的 地 方 ， 父 类 未 必 就 可 以 胜任 。 还 是 以 刚才 的 关于 枪支 
的 例子 为 例 ， 步 检 有 几 个 比较 “响亮 ?的 型 号 ， 比 如 AK47、AUG 狙 击 步 
枪 等 ， 把 这 两 个 型 号 的 枪 引 入 后 的 Rifle 子 类 图 如 图 2-4 所 示 。 















-AUG aug 


+void setGun(AUG aug) 


+vold killEnemy() 


图 2-4 增加 AK47 和 AUG 后 的 Rifle 子 类 图 


很 简单 ，AUG 继 承 了 Rifle 类 ， 狙 击 手 〈Snipper) 则 直接 使 用 AUG 


狙击 步枪 ， 源 代码 如 代码 清单 2-7 所 示 。 


代码 清单 2-7 AUG 狙 击 枪 源码 代码 


public class AUG extends Rifle { 


// 狙 击 枪 都 携带 一 个 精准 的 望远镜 
public void zoomOut(){ 
System.out.printlLn(" 通 过 望远镜 察看 敌人 ,,.")， 


} 
public void shoot()t{ 

System.out ,println("AUG 射 击 .. .1")， 
} 





有 狙击 枪 残 有 狙击 手 ， 狙 击 手 类 的 源 代码 如 代码 清单 2-8 所 示 。 


代码 清单 2-8 AUG 狙 击 手 类 的 源码 代码 


public class Snipper { 


public void killEnemy(AUG aug)t 
// 首 先 看 看 敌人 的 情况 ， 别 杀 死 敌人 ， 自 己 也 被 人 干掉 
aug .zoomOut( ) ， 


// 开 始 射击 








aug. shoot(); 


狙击 手 ， 为 什么 叫 Snipper?Snipe 翻 译 过 来 就 是 天 ， 就 是 “ 裔 蚌 相 
和 争 ， 渔 人 得 利 ” 中 的 那 只 乌 ， 英 国 贵 族 到 印度 打猎 ， 发 现 这 个 德 很 聪 
明 ， 人 一 靠近 就 飞 走 了 ， 没 办 法 就 开始 伪装 、 远 程 精 准 射 击 ， 于 是 卑 
Snipper 就 诞生 了 。 


狙击 手 使 用 狙击 枪 来 杀 死 敌人 人， 业务 场 景 Client 类 的 源 代 码 如 代码 
清单 2-9 所 示 。 


代码 清单 2-9 狙击 手 使 用 AUG 杀 死敌 人 


public class Client { 
public static void main(String[|] args) { 
// 产 生 三 毛 这 个 狙击 手 
Snipper sanMao = new Snipper(); 
sanMao. setRifle(new AUG() ) ; 
sanMao.killEnemy( ) ; 





狙击 手 使 用 G3 杀 死 政 人 ， 运 行 结果 如 下 所 示 : 





通过 望远镜 察看 敌人 ... 











AUG 射 击 .… 

在 这 里 ， 系 统 直 接 调用 了 子 类 ， 狙 击 手 是 很 依赖 枪 文 的 ， 别 说 换 一 
个 型 号 的 枪 了 ， 束 是 换 一 个 同型 号 的 枪 也 会 影响 射击 ， 所 以 这 里 就 直接 
把 子 类 传递 了 进来 。 这 个 时 候 ， 我 们 能 不 能 直接 使 用 父 类 传递 进来 呢 ? 





修改 一 下 Client 类 ， 如 代码 清单 2-10 所 示 。 


代码 清单 2-10 使 用 父 类 作为 参数 


public class Client { 
public static void main(String[|] args) { 
// 产 生 三 毛 这 个 狙击 手 
Snipper SanMao = new Snipper(); 
sanMao. setRifle( (AUG) (new Rifle( ))); 
sanMao.killEnemy( ); 





ww 


显示 是 不 行 的 ， 会 在 运行 期 抛 出 java.lang.ClassCastException 异 和 常 ， 
这 也 是 大 家 经 常 说 的 癌 下 转型 (downcast) 是 不 安全 的 ， 从 里 氏 蔡 换 原 
则 来 看 ， 就 是 有 子 类 出 现 的 地 方 父 类 未 必 束 可 以 出 现 。 





3. 履 盖 或 实现 父 类 的 方法 时 输入 参数 可 以 被 放大 


方法 中 的 输入 参数 称 为 前 置 条 件 ， 这 是 什么 意思 呢 ? 大 家 做 过 Web 
Service 开 发 就 应 该 知道 有 一 个 “契约 优先 ”的 原则 ， 也 就 是 先 定义 出 
WSDL 接 口 ， 制 定好 双方 的 开发 协议 ， 然 后 再 各 自 实现 。 里 氏 蔡 换 原 则 
也 要 求 制定 一 个 契约 ， 就 是 父 类 或 接口 ， 这 种 设计 方法 也 叫做 Design by 
Contract〈 契 约 设 计 ) ， 与 里 氏 蔡 换 原则 有 着 异曲同工 之 妙 。 契 约 制定 
了 ， 也 就 同时 制定 了 前 置 条 件 和 后 置 条 件 ， 前 置 条 件 就 是 你 要 让 我 执 
行 ， 就 必须 满足 我 的 条 件 ， 后 置 条 件 就 是 我 执行 完了 需要 反馈 ， 标 准 是 
什么 。 这 个 比较 难 理解 ， 我 们 来 看 一 个 例子 ， 我 们 先 定义 一 个 Father 
类 ， 如 代码 清单 2-11 所 示 。 














代码 清单 2-11 Father 类 源 代 码 


public class Father { 
public Collection doSomething(HashMap map)t{ 
System.out.printlin(" 父 类 被 执行 ...")， 
return map.values(); 


这 个 类 非常 简单 ， 就 是 把 HashMap 转 换 为 Collection 集 合 类 型 ， 然 后 
再 定义 一 个 子 类 ， 源 代码 如 代码 清单 2-12 所 示 。 


代码 清单 2-12 子 类 源 代码 


public class Son extends Father { 
// 放 大 输入 参数 类 型 
public Collection doSomething(Map map)t 
System.out.printlin(" 子 类 被 执行 ...")，; 
return map.values(); 


你 加 个 @Override 试 试看 ， 会 报错 的 ， 为 什么 呢 ? 方法 名 虽然 相 
同 ， 但 方法 的 输入 参数 不 同 ， 就 不 是 履 写 ， 那 这 是 什么 呢 ? 是 重 载 
《Overload) ! 不 用 大 惊 小 怪 的 ， 不 在 一 个 类 就 不 能 是 重 载 了 ? 继承 是 
什么 意思 ， 子 类 拥有 父 类 的 所 有 属性 和 方法 ， 方 法 名 相同 ， 输 入 参数 类 
型 又 不 相同 ， 当 然 是 重 载 7 。 父 类 和 子 类 都 已 经 声明 了， 场景 类 的 调用 
如 代码 清单 2-13 所 示 。 








代码 清单 2-13 场景 类 源 代码 


public class Client { 
public static void invoker()t{ 


// 父 类 存在 的 地 方 ， 子 类 就 应 该 能 够 存在 
Father f = new Father(); 
HashMap map = new HashMap() ， 
f.doSsomething(map); 


public static void main(String[] args) { 
invoker( ); 


代码 运行 后 的 结果 如 下 所 示 : 
父 类 被 执行 … 


根据 里 氏 替 换 原 则 ， 父 类 出 现 的 地 方 子 类 就 可 以 出 现 ， 如 代码 清单 
2-14 所 示 。 


代码 清单 2-14 子 类 普 换 父 类 后 的 源 代码 


public class Client { 
public static void invoker()t{ 
// 父 类 存在 的 地 方 ， 子 类 就 应 该 能 够 存在 
Son f =new Son(); 
HashMap map = new HashMap(); 
f.doSsomething(map); 


public static void main(String[] args) { 
invoker(); 
} 


运行 结果 还 是 一 样 ， 看 明白 是 怎么 回 事 了 吗 ? 父 类 方法 的 输入 参数 
征 HashMap 类 型 ， 子 类 的 输入 参数 是 Map 类 型 ， 也 就 是 说 子 类 的 输入 参 
数 类 型 的 范围 扩大 了 ， 子 类 代 葵 父 类 传递 到 调用 者 中 ， 子 类 的 方法 永远 
都 不 会 被 执行 。 这 是 正确 的 ， 如 果 你 想 让 子 类 的 方法 运行 ， 就 必须 覆 写 
父 类 的 方法 。 大 家 可 以 这 样 想 ， 在 一 个 Invoker 类 中 关联 了 一 个 父 类 ， 调 


用 了 一 个 父 类 的 方法 ， 子 类 可 以 缆 写 这 个 方法 ， 也 可 以 重 载 这 个 方法 ， 
前 提 是 要 扩大 这 个 前 置 条 件 ， 就 是 输入 参数 的 类 型 澳 于 父 类 的 类 型 禾 兰 
范围 。 这 样 说 可 能 比较 难 理解 ， 我 们 再 反 过 来 想 一 下 ， 如 果 Father 关 的 
输入 参数 类 型 宽 于 子 类 的 输入 参数 类 型 ， 会 出 现 什么 问题 呢 ? 会 出 现 父 
类 存在 的 地 方 ， 子 类 就 未 必 可 以 存在 ， 因 为 一 旦 把 子 类 作为 参数 传 入 ， 
调用 者 就 很 可 能 进入 子 类 的 方法 范畴 。 我 们 把 上 面 的 例子 修改 一 下 ， 扩 
大 父 类 的 前 置 条 件 ， 源 代码 如 代码 清早 2-15 所 示 。 





代码 清单 2-15 父 类 的 前 置 条 件 较 大 


public class Father { 
public Collection doSomething(Map map)t 
System.out.printlin(" 父 类 被 执行 ...")， 
return map.values(); 


把 父 类 的 前 置 条 件 修改 为 Map 类 型 ， 我 们 再 修改 一 下 子 类 方法 的 输 
入 参数 ， 相 对 父 类 缩小 输入 参数 的 类 型 范围 ， 也 惑 是 缩小 前 置 条 件 ， 源 
代码 如 代码 清单 2-16 所 示 。 


代码 清单 2-16 子 类 的 前 置 条 件 较 小 


public class Son extends Father { 
// 缩 小 输入 参数 范围 
public Collection doSomething(HashMap map)t{ 
System.out.printlin(" 子 类 被 执行 ...")， 
return map.values(); 


在 父 类 的 前 置 条 件 大 于 子 类 的 前 置 条 件 的 情况 下 ， 


码 如 代码 清单 2-17 所 示 。 


代码 清单 2-17 子 类 的 前 置 条 件 较 小 


public class Client { 
public static void invoker()t{ 
// 有 父 类 的 地 方 就 有 子 类 
Father f= new Father(); 
HashMap map = new HashMap(); 
f.doSsomething(map); 








public static void main(String[] args) { 
invoker(); 


代码 运行 结果 如 下 所 示 : 


父 类 被 执行 … 


业务 场景 的 源 代 


那 我 们 再 把 里 氏 答 换 原则 引入 进来 会 有 什么 问题 ? 有 父 类 的 地 方 子 
类 就 可 以 使 用 ， 好 ， 我 们 把 这 个 Client 类 修改 一 下 ， 源 代码 如 代码 清单 


2-18 所 示 。 


代码 清单 2-18 采用 里 氏 丛 换 原 则 后 的 业务 场景 类 


public class Client { 
public static void invoker()t{ 
// 有 父 类 的 地 方 就 有 子 类 
Son f =new Son(); 
HashMap map = new HashMap(); 
f.doSsomething(map); 








public static void main(String[] args) { 
invoker(); 
} 


代码 运行 后 的 结果 如 下 所 示 : 
子 类 被 执行.. 


完 抹 了 吧 ? ! 子 类 在 没有 和 履 写 父 类 的 方法 的 前 提 下 ， 子 类 方法 个 执 
了 了， 这 会 引起 业务 逻辑 混乱 ， 因 为 在 实际 应 用 中 父 类 一 般 部 是 抽象 
类 ， 子 类 是 实现 类 ， 你 传递 一 个 这 样 的 实现 类 就 会 “ 窒 曲 ”了 父 类 的 意 
图 ， 引 起 一 堆 意 想不到 的 业务 逻辑 混乱 ， 所 以 子 类 中 方法 的 前 置 条 件 必 
须 与 超 类 中 被 履 写 的 方法 的 前 置 条 件 相同 或 者 更 宽松 。 


—~、 











4. 禾 写 或 实现 父 类 的 方法 时 输出 结果 可 以 被 缩小 





这 是 什么 意思 呢 ， 父 类 的 一 个 方法 的 返回 值 是 一 个 类 型 T， 子 类 的 
相同 方法 〈 重 载 或 覆 写 ) 的 返回 值 为 S， 那 么 里 氏 蔡 换 原 则 就 要 求 S 必 须 
小 于 等 于 T， 也 就 是 说 ， 要 么 S 和 TT 是 同一 个 类 型 ， 要 么 S 是 T 的 子 类 ， 为 
什么 呢 ? 分 两 种 情况 ， 如 果 是 履 写 ， 父 类 和 子 类 的 同名 方法 的 输入 参数 
是 相同 的 ， 两 个 方法 的 范围 值 S 小 于 等 于 T， 这 是 履 写 的 要 求 ， 这 才 是 重 
中 之 重 ， 子 类 履 写 父 类 的 方法 ， 天 经 地 义 。 如 果 是 重 载 ， 则 要 求 方法 的 
输入 参数 类 型 或 数量 不 相同 ， 在 里 氏 蔡 换 原 则 要 求 下 ， 就 是 子 类 的 输入 
参数 宽 于 或 等 于 父 类 的 输入 参数 ， 也 就 是 说 你 写 的 这 个 方法 是 不 会 被 调 
用 的 ， 参 考 上 面 讲 的 前 置 条 件 。 














采用 里 氏 玲 换 原则 的 目的 就 是 增强 程序 的 健壮 性 ， 版 本 升级 时 也 可 





以 保持 非常 好 的 兼容 性 。 即 使 增加 子 类 ， 原 有 的 子 类 还 可 以 继续 运行 。 
在 实际 项 目 中 ， 每 个 子 类 对 应 不 同 的 业务 含义 ， 使 用 父 类 作为 参数 ， 传 
递 不 同 的 子 类 完成 不 同 的 业务 逻辑 ， 非 常 完 美 ! 





2.3 最 佳 实践 


在 项 目 中 ， 采 用 里 氏 丛 换 原 则 时 ， 尽 量 避 免 子 类 的 “个 性 ”， 一 旦 子 
类 有 “个 性 ?， 这 个 子 类 和 父 类 之 间 的 关系 就 很 难 调 和 了 ， 把 子 类 当做 父 
类 使 用 ， 子 类 的 “个 性 ”被 抹杀 一 一 委 届 了 扣 ; 把 子 类 单独 作为 一 个 业务 
来 使 用 ， 则 会 让 代码 间 的 厢 合 关系 变 得 扑朔迷离 一 一 缺乏 类 丛 换 的 标 
准 。 





第 3 草 ”依赖 倒置 原则 


3.1 依赖 倒置 原则 的 定义 


依赖 倒置 原则 (Dependence Inversion Principle,DIP) 这 个 名 字 看 着 
有 点 别扭 , “依赖 ?还 “倒置 >， 这 到 底 是 什么 意思 ? 依赖 倒置 原则 的 原始 


定义 是 : 


High level modules should not depend upon low level modules.Both 
should depend upon abstractions.Abstractions should not depend upon 


details.Details should depend upon abstractions. 
翻译 过 来 ， 包 含 三 层 含义 : 
e 高 层 模 块 不 应 该 依赖 低层 模块 ， 两 者 都 应 该 依赖 其 抽象 
e 抽象 不 应 该 依赖 细节 


e 细 蔬 应 该 依赖 抽象 。 





高 层 模 块 和 低层 模块 容易 理解 ， 每 一 个 馆 辑 的 实现 都 是 由 原子 馆 辑 
组 成 的 ， 不 可 分 割 的 原子 逻辑 残 是 低层 模块 ， 原 子 逻 辑 的 再 组 装束 是 高 
层 模块 。 那 什么 是 抽象 ? 什么 又 是 细节 呢 ? 在 Java 语 言 中 ， 抽 象 就 是 指 





接口 或 抽象 类 ， 两 者 都 是 不 能 直接 个 实例 化 的 ;细节 就 是 实现 类 ， 实 现 
接口 或 继承 抽象 类 而 产生 的 类 束 是 细 市 ， 其 特点 就 是 可 以 直接 被 实例 
化 ， 也 就 是 可 以 加 上 一 个 关键 字 new 产 生 一 个 对 象 。 依 赖 倒 置 原则 在 
Java 语 言 中 的 表现 就 是 : 





e 模块 间 的 依赖 通过 抽象 发 生 ， 实 现 类 之 间 不 发 生 直 接 的 依赖 关 
系 ， 其 依赖 关系 是 通过 接口 或 抽象 类 产生 的 ; 


e 接口 或 抽象 类 不 依赖 于 实现 类 ; 


e 实现 类 依赖 接口 或 抽象 类 。 





更 加 精简 的 定义 就 是 “面向 接口 编程 ”OOD (Object-Oriented 
Design， 面 向 对 象 设 计 ) 的 精髓 之 一 。 


3.2 言 而 无 信 ， 你 太 需 要 契约 


采用 依赖 倒置 原则 可 以 减少 类 间 的 耘 合 性 ， 提 高 系统 的 稳定 性 ， 降 
低 并 行 开 发 引起 的 风险 ， 提 高 代码 的 可 读 性 和 可 维护 性 。 


证 明 一 个 定理 是 否 正 确 ， 有 两 种 常用 的 方法 : 一 种 是 根据 提出 的 论 
题 ， 经 过 一 看 论 证 ， 推 出 和 定理 相同 的 结论 ， 这 是 顺 推 证 法 ;还 有 一 种 
古 首先 假设 提出 的 命题 是 伪 命 题 ， 然 后 推导 出 一 个 元 座 、 与 已 知 条 件 互 
斥 的 结论 ， 这 是 反 证 法 。 我 们 今天 就 用 反 证 法 来 证 明 依赖 倒置 原则 是 多 
么 优秀 和 伟大 ! 





论题 : 依赖 倒置 原则 可 以 减少 类 间 的 耦合 性 ， 提 高 系统 的 稳定 
性 ， 降 低 并 行 开 发 引起 的 风险 ， 提 高 代码 的 可 读 性 和 可 维护 性 。 


反 论 题 : 不 使 用 依赖 倒置 原则 也 可 以 减少 类 间 的 耦合 性 ， 提 高 系 
统 的 稳定 性 ， 降 低 并 行 开 发 引起 的 风险 ， 提 高 代码 的 可 读 性 和 可 维护 
全 





我 们 通过 一 个 例子 来 说 明 反 论题 是 不 成 立 的 。 现 在 的 汽车 越 来 越 便 
宜 了 ， 一 个 卫生 间 的 造价 就 可 以 买 到 一 辆 不 错 的 汽车 ， 有 汽车 就 必然 有 
人 来 要 驶 ， 司 机 四 驶 奔驰 车 的 类 图 如 图 3-1 所 示 。 








图 3-1 司机 要 驶 奔驰 车 类 疼 


奔驰 车 可 以 提供 一 个 方法 run， 人 代表 车 辆 运行 ， 
单 3-1 所 示 。 


代码 清单 3-1 司机 源 代 码 


public class Driver { 
// 司 机 的 主要 职 内 次 训 就 是 是 驾驶 汽 村 
public void drive(Benz benz){ 
benz.run(); 
小 








司机 通过 调用 奔驰 车 的 run 方 法 开动 奔驰 车 ， 其 
2 所 示 。 


代码 清单 3-2 奔驰 车 源 代码 








public class Co { 





public 8， run()t{ 


a 


System.out.println(" 奔 驰 汽 车 开始 运行 .， 


实现 过 程 如 代码 清 


其 源 代 码 如 代码 清单 3- 


有 车 ， 有 司机 ， 在 Client 场 景 类 产生 相应 的 对 象 ， 其 源 代 码 如 代码 
清单 3-3 所 示 。 


代码 清单 3-3 场景 类 源 代码 


public class Client { 
public static void main(String[|] args) { 
Driver zhangSan = new Driver(); 
Benz benz = new Benz(); 
// 张 三 开 奔 驰 车 


zhangSan.drive(benz); 


通过 以 上 的 代码 ， 完 成 了 司机 开动 奔驰 车 的 场景 ， 到 目前 为 止 ， 这 
个 司机 开 奔 驰 车 的 项 目 没有 任何 问题 。 我 们 常 说 “危难 时 刻 见 真情 ”， 我 
们 把 这 句 话 移植 到 技术 上 就 成 了 “变更 才 显 真 功 夫 ”， 业 务 需 求 变更 永 无 
休止 ， 技 术 前 进 就 永 无 止境 ， 在 发 生变 更 时 才能 发 觉 我 们 的 设计 或 程序 
是 否 是 松 耦 合 。 我 们 在 一 段 貌 似 痪 石 的 程序 上 加 上 一 块 小 石头 : 张 三 司 
机 不 仅 要 开 和 奔驰 车 ， 还 要 开 宝 马车 ， 又 该 怎么 实现 呢 ? 麻 烦 出 来 了 ， 那 
好 ， 我 们 走 一 步 是 一 步 ， 我 们 先 把 宝马 车 产生 出 来 ， 实 现 过 程 如 代码 清 
单 3-4 所 示 。 














代码 清单 3-4 宝马 车 源 代码 


public class BMW { 
// 宝 马车 当然 也 可 以 开动 了 
public void run(){ 
System.out.println(" 宝 马 汽车 开始 运行 ..."); 





宝马 车 也 产生 了 ， 但 是 我 们 却 没 有 办 法 让 张 三 开动 起 来 ， 为 什么 ? 
张 三 没 有 开动 宝马 车 的 方法 呀 ! 一 个 全 有 C 轰 照 的 司机 竟然 只 能 开 奔驰 
车 而 不 能 开 宝马 车 ， 这 也 太 不 合理 了 ! 在 现实 世界 都 不 允许 存在 这 种 情 
况 ， 何 况 程 序 还 是 对 现实 世界 的 抽象 ， 我 们 的 设计 出 现 了 问题 : 司机 类 
和 奔驰 车 类 之 间 是 紧 耦 合 的 关系 ， 其 导致 的 结果 就 是 系统 的 可 维护 性 大 
大 降低 ， 可 读 性 降低 ， 两 个 相似 的 类 需要 阅读 两 个 文件 ， 你 乐意 吗 ? 还 
有 稳定 性 ， 什 么 是 稳定 性 ? 固化 的 、 健 壮 的 才 是 稳定 的 ， 这 里 只 是 增加 
了 一 个 车 类 就 需要 修改 司机 类 ， 这 不 是 稳定 性 ， 这 是 易 变 性 。 被 依赖 者 
的 变更 竟然 让 依赖 者 来 承担 修改 的 成 本 ， 这 样 的 依赖 关系 谁 肯 承担 ! 证 
明 到 这 里 ， 我 们 已 经 知道 反 论题 已 经 部 分 不 成 并 了 。 

















注意 设计 是 否 具备 稳定 性 ， 只 要 适当 地 * 松 松 土 "， 观 察 “设计 的 
蓝图 "是 否 还 可 以 苗 壮 地 成 长 就 可 以 得 出 结论 ， 稳 定性 较 高 的 设计 ， 在 
周围 环境 频繁 变化 的 时 候 ， 依 然 可 以 做 到 “我 自 央 然 不 动 ”。 





我 们 继续 证 明 , “减少 并 行 开 发 引起 的 风险 ?”， 什 么 是 并 行 开 发 的 风 
险 ? 并 行 开发 最 大 的 风险 就 是 风险 扩散 ， 本 来 只 是 一 段 程序 的 错误 或 姑 
常 ， 逐 步 波 及 一 个 功能 ， 一 个 模块 ， 甚 至 到 最 后 蝶 坏 了 整个 项 目 。 为 什 
么 并 行 开 及 就 有 这 样 的 风险 呢 ? 一 个 团队 ，20 个 开 及 人 员 ， 各 人 负责 不 
同 的 功能 模块 ， 甲 负责 汽车 类 的 建造 ， 乙 负责 司机 类 的 建造 ， 在 甲 没 有 





完成 的 情况 下 ， 乙 是 不 能 完全 地 编写 代码 的 ， 缺 少 汽车 类 ， 编 译 器 根本 
就 不 会 让 你 通过 ! 在 缺少 Benz 类 的 情况 下 ，Driver 类 能 编译 吗 ? 更 不 要 
说 是 单元 测试 了 ! 在 这 种 不 使 用 依赖 倒置 原则 的 环境 中 ， 所 有 的 开发 工 
作 都 是 “单线 程 * 的 ， 甲 做 完 ， 乙 再 做 ， 然 后 是 丙 继续 ..……... 这 在 20 世 纪 90 
年 代 “ 个 人 英雄 主义 ”编程 模式 中 还 是 比较 适用 的 ， 一 个 人 完成 所 有 的 代 
码 工作 。 但 在 现在 的 大 中 型 项 目 中 已 经 是 完全 不 能 胜任 了 ， 一 个 项 目 是 
一 个 团队 协作 的 结果 ， 一 个 “英雄 ?再 牛 也 不 可 能 了 解 所 有 的 业务 和 所 有 
的 技术 ， 要 协作 就 要 并 行 开 发 ， 要 并 行 开发 就 要 解决 模块 之 间 的 项 目 依 
赖 关 系 ， 那 然后 呢 ? 依赖 倒置 原则 就 隆重 出 场 了 ! 














根据 以 上 证 明 ， 如 宋 不 使 用 依赖 倒置 原则 就 会 加 重 类 间 的 耦合 性 ， 
降低 系统 的 稳定 性 ， 增 加 并 行 开发 引起 的 风险 ， 降 低 代码 的 可 读 性 和 可 
维护 性 。 承 接 上 面 的 例子 ， 引 入 依赖 倒置 原则 后 的 类 图 如 图 3-2 所 示 。 


<<Interface>> <<Imnterface>> 
IDriver ICar 





+void driver(ICar car) +void run() 


人 


Driver BMYW Benz 
EE 二 = = = 
| | LL =4 





图 3-2 引入 依赖 倒置 原则 后 的 类 图 


建立 两 个 接口 : IDriver 和 ICar， 分 别 定 义 了 司机 和 汽车 的 各 个 职 
EE， 司机 就 是 敬 驶 汽车 ， 必 须 实现 drive() 方 法 ， 其 实现 过 程 如 代码 清单 
3-5 所 示 。 


代码 清单 3-5 司机 接口 


public interface 8 { 
// 是 司机 就 应 该 会 驾驶 汽车 


public void | Car ) ， 


接口 只 是 一 个 抽象 化 的 概念 ， 是 对 一 类 事物 的 最 抽象 描述 ， 有 具体 的 
实现 代码 由 相应 的 实现 类 来 完成 ，Driver 实 现 类 如 代码 清单 3-6 所 示 。 


代码 清单 3-6 司机 类 的 实现 


public class Driver implements IDrivert{ 
// 司 机 的 主要 职 内 次 训 就 是 是 驾驶 汽 气 车 
public void drive(ICar car)t{ 
car.run(); 
} 








在 IDriver 中 ， 通 过 传 入 ICar 接 口 实现 了 抽象 之 间 的 依赖 关系 ， 
Driver 实 现 类 也 传 入 了 ICar 接 口 ， 至 于 到 底 是 哪个 型 号 的 Car， 需 要 在 高 
层 模块 中 声明 。 





ICar 及 其 两 个 实现 类 的 实现 过 程 如 代码 清单 3-7 所 示 。 


代码 清单 3-7 汽车 接口 及 两 个 实现 类 


public interface ICar { 


// 是 汽车 束 应 该 能 跑 
public void run(); 


public class Benz implements ICart{ 
// 汽 车 肯定 会 跑 
public void run(){ 
System.out.println(" 奔 驰 汽 车 开始 运行 ..."); 
} 


public class BMW implements ICart{ 
// 宝 马车 当然 也 可 以 开动 了 
public void run(){ 
System.out.println(" 宝 杞 汽车 开始 运行 ...")， 
} 








在 业务 场景 中 ， 我 们 贯彻 “抽象 不 应 该 依赖 细节 ”， 也 就 是 我 们 认为 
抽象 〈ICar 接 口 ) 不 依赖 BMW 和 了 Benz 两 个 实现 类 〈 细 节 ) ， 因 此 在 高 
层次 的 模块 中 应 用 都 是 抽象 ，Client 的 实现 过 程 如 代码 清单 3-8 所 示 。 





代码 清单 3-8 业务 场景 


public class Client { 
public static void main(String[] args) { 
IDriver zhangSan = new Driver(); 
ICar benz = new Benz(); 
// 张 三 开 奔驰 车 


zhangSan.drive(benz); 


Client 属 于 高 层 业 务 逻 辑 ， 它 对 低层 模块 的 依赖 都 建立 在 抽象 上 ， 
zhangSan 的 表面 类 型 是 IDriver，Benz 的 表面 类 型 是 ICar， 也 许 你 要 问 ， 
在 这 个 高 层 模块 中 也 调用 到 了 低层 模块 ， 比 如 new Driver() 和 new Benz() 
等 ， 如 何 解 释 ? 确实 如 此 ，zhangSan 的 表面 类 型 是 IDriver， 是 一 个 接 
口 ， 是 抽象 的 、 非 实体 化 的 ， 在 其 后 的 所 有 操作 中 ，zhangSan 都 是 以 





IDriver 类 型 进行 操作 ， 屏 项 了 细节 对 抽象 的 影响 。 当 然 ， 张 三 如 果 要 开 
宝马 车 ， 也 很 容易 ， 我 们 只 要 修改 业务 场景 类 就 可 以 ， 实 现 过程 如 代码 
清单 3-9 所 示 。 





代码 清单 3-9 张 三 轨 驶 宝马 车 的 实现 过 程 


public class Client { 
public static void main(String[] args) { 
IDriver zhangSan = new Driver(); 
ICar bmw = new BMW( ) ; 
// 张 三 开 奔驰 车 
zhangSan.drive(bmw); 


在 新 增加 低层 模块 时 ， 只 修改 了 业务 场景 类 ， 也 就 是 高 层 模块 ， 对 
其 他 低层 模块 如 Driver 类 不 需要 做 任何 修改 ， 业 务 就 可 以 运行 ， 把 “ 变 
更 ?引起 的 风险 扩散 降 到 最 低 。 





注意 ”在 Java 中 ， 只 要 定义 变量 就 必然 要 有 类 型 ， 一 个 变量 可 以 有 
两 种 类 型 : 表面 类 型 和 实际 类 型 ， 表 面 类 型 是 在 定义 的 时 候 赋予 的 类 
型 ， 实 际 类 型 是 对 象 的 类 型 ， 如 zhangSan 的 表面 类 型 是 IDriver， 实 际 类 


型 是 Driver。 





我 们 再 来 思考 依赖 倒置 对 并 行 开 发 的 影响 。 两 个 类 之 间 有 依赖 关 
系 ， 只 要 制定 出 两 者 之 间 的 接口 (或 抽象 类 ) 就 可 以 独立 开发 了 ， 而 且 
项 目 之 间 的 单元 测试 也 可 以 独立 地 运行 ， 而 TDD (Test-Driven 





Development， 测 试 驱动 开发 ) 开发 模式 就 是 依赖 倒置 原则 的 最 高 级 应 
用 。 我 们 继续 回顾 上 面 司机 驾驶 汽车 的 例子 ， 甲 程序 员 负 责 IDriver 的 开 
发 ， 乙 程序 员 负 责 ICar 的 开发 ， 两 个 开发 人 员 只 要 制定 好 了 接口 就 可 以 
独立 地 开发 了 ， 甲 开发 进度 比较 快 ， 完 成 了 IDriver 以 及 相关 的 实现 类 
Driver 的 开发 工作 ， 而 乙 程 序 员 滞后 开发 ， 那 甲 是 否 可 以 进行 单元 测试 
呢 ? 答案 是 可 以 ， 我 们 引入 一 个 JMock 工 具 ， 其 最 基本 的 功能 是 根据 抽 
象 虚拟 一 个 对 象 进行 测试 ， 测 试 类 如 代码 清单 3-10 所 示 。 


代码 清单 3-10 测试 类 


public class DriverTest extends TestCaset 

Mockery context = new JUnit4Mockery(); 

@Test 

public void testDriver() { 
// 根 据 接口 虚拟 一 个 对 象 
final ICar car = context ,mock(ICar.class ) ; 
IDriver driver = new Driver(); 
// 内 部 类 
context.checking(new Expectations(){t{ 

oneof (car).run(); 

}}); 


driver.drive(car); 





从 这 一 点 来 看 ， 两 个 相互 依赖 的 对 象 可 以 分 别 进行 开发 ， 扳 立地 进 
行 单元 测试 ， 进 而 保证 并 行 开 发 的 效率 和 质量 ，TDD 开 发 的 精 骨 不 就 在 
这 里 吗 ? 测试 驱动 开 友 ， 先 写 好 单元 测试 类 ， 然 后 再 写实 现 类 ， 这 对 提 
局 代码 的 质量 有 非常 大 的 帮助 ， 特 别 适合 研发 类 项 目 或 在 项 目 成 员 整 体 
水 平 比较 低 的 情况 下 采用 。 











抽象 是 对 实现 的 约束 ， 对 依赖 者 而 言 ， 也 是 一 种 契约 ， 不 仅仅 约束 
自己， 还 同时 约束 自己 与 外 部 的 关系， 其 目的 是 保证 所 有 的 细 市 不 脱离 
契约 的 范畴 ， 确 保 约 束 双 方 按照 既定 的 契约 《抽象 ) 共同 发 展 ， 只 要 抽 
象 这 根基 线 在 ， 细 市 就 脱离 不 了 这 个 圈 财 ， 始 终 让 你 的 对 象 做 到 “ 言 必 








入 》 行 必 果 ” o 


3.3 依赖 的 三 种 写法 


依赖 是 可 以 传递 的 ，A 对 象 依赖 B 对 象 ，B 又 依赖 C，C 又 依赖 D..………… 
生生 不 轧 ， 依 赖 不 止 ， 记 住 一 点 : 只 要 做 到 抽象 依赖 ， 即 使 是 多 层 的 依 
赖 传递 也 无 所 长 惧 ! 





对 象 的 依赖 关系 有 三 种 方式 来 传递 ， 如 下 所 示 。 


1. 构 造 函 数 传 递 依 赖 对 象 





在 类 中 通过 构造 函数 声明 依赖 对 象 ， 按 照 依 赖 注 入 的 说 法 ， 这 种 方 
式 叫 做 构造 图 数 注 入 ， 按 照 这 种 方式 的 注入 ，IDriver 和 Driver 的 程序 修 
改 后 如 代码 清单 3-11 所 示 。 





代码 清单 3-11 构造 浮 数 传递 依赖 对 象 


public interface IDriver { 
// 是 司机 就 应 该 会 驾驶 汽车 
public void drive()， 


} 
public class Driver implements IDrivert{ 
private ICar car; 


// 构 造 函 数 注 入 
public Driver(ICar _car)t{ 
this.car = _car,; 











} 

// 司 机 的 主要 职员 就 是 驾驶 汽车 

public void drivel(){ 
this.car.run(); 

} 


2.Setter 方 法 传递 依赖 对 象 


在 抽象 中 设置 Setter 方 法 声明 依赖 关系 ， 依 照 依赖 注入 的 说 法 ， 这 
是 Setter 依 赖 注入 ， 按 照 这 种 方式 的 注入 ，IDriver 和 Driver 的 程序 修改 后 
如 代码 清单 3-12 所 示 。 





代码 清单 3-12 Setter 依 赖 注 入 


public interface IDriver { 
// 车 辆 型 号 
public void setCar(ICar car); 
// 是 司机 就 应 该 会 驾驶 汽车 
public void drive( ); 


} 
public class Driver implements IDrivert{ 
private ICar car; 
public void setCar(ICar car ){ 
this.car = car; 


} 

// 司 机 的 主要 职 贡 就 是 驾驶 汽车 

public void drivel( ){ 
this.car.run(); 

} 








3. 接 口 声明 依赖 对 象 





在 接口 的 方法 中 声明 依赖 对 象 ，3.2 节 的 例子 就 采用 了 接口 声明 依 
赖 的 方式 ， 该 方法 也 叫做 接口 注入 。 


3.4 最 佳 实践 


依赖 倒置 原则 的 本 质 束 是 通过 抽象 接口 或 抽象 类 ) 使 各 个 类 或 模 
块 的 实现 彼此 独立 ， 不 互相 影响 ， 实 现 模 块 间 的 松 厢 合 ， 我 们 怎么 在 项 
目 中 使 用 这 个 规则 呢 ? 只 要 遵循 以 下 的 几 个 规则 就 可 以 : 














e 每 个 类 尽量 都 有 接口 或 抽象 类 ， 或 者 抽象 类 和 接口 两 者 都 具备 


这 是 依赖 倒置 的 基本 要 求 ， 接 口 和 抽象 类 都 是 属于 抽象 的 ， 有 了 抽 
象 才 可 能 依赖 倒置 。 








e 变量 的 表面 类 型 尽量 是 接口 或 者 是 抽象 类 





很 多 书 上 说 变量 的 类 型 一 定 要 是 接口 或 者 是 抽象 类 ， 这 个 有 扣 绝 对 
化 了 ， 比 如 一 个 工具 类 ，xxxUtils 一 般 是 不 需要 接口 或 是 抽象 类 的 。 还 
有 ， 如 果 你 要 使 用 类 的 clone 方 法 ， 就 必须 使 用 实现 类 ， 这 个 是 JDK 提 供 


的 一 个 规范 。 








e 任何 类 都 不 应 该 从 具体 类 派生 





如 果 一 个 项 目 处 于 开发 状态 ， 确 实 不 应 该 有 从 其 体 类 派生 出 子 类 的 
情况 ， 但 这 也 不 是 绝对 的 ， 因 为 人 都 是 会 犯错 误 的 ， 有 时 设计 缺陷 是 在 
所 难免 的 ， 因 此 只 要 不 超过 两 层 的 继承 都 是 可 以 忍受 的 。 特 别 是 负责 项 








目 维护 的 同 六， 基本 上 可 以 不 考虑 这 个 规则 ， 为 什么 ? 维护 工作 基本 上 
都 是 进行 扩展 开发 ， 修 复 行为 ， 通 过 一 个 继承 关系， 和 履 写 一 个 方法 就 可 
以 修正 一 个 很 大 的 Bug， 何 必 去 继承 最 高 的 基 类 呢 ? (当然 这 种 情况 尽 
量 发 生 在 不 其 了 解 父 类 或 者 无 法 获得 父 类 代码 的 情况 下 。) 

















如 果 基 类 是 一 个 抽象 类 ， 而 且 这 个 方法 已 经 实现 了 ， 子 类 尽量 不 要 
履 写 。 类 间 依 赖 的 是 抽象 ， 窗 写 了 抽象 方法 ， 对 依赖 的 稳定 性 会 产 
定 的 影 啊 。 





e 结合 里 氏 蕉 换 原 则 使 用 


在 第 2 章 中 我 们 讲解 了 里 氏 蔡 换 原 则 ， 父 类 出 现 的 地 方 子 类 束 能 
现 ， 再 结合 本 章 的 讲解 ， 我 们 可 以 得 出 这 样 一 个 通俗 的 规则 :， 接口 负 
员 定 义 public 属 性 和 方法 ， 并 且 声 明 与 其 他 对 象 的 依赖 关系， 抽象 类 负 
责 公共 构造 部 分 的 实现 ， 实 现 类 准确 的 实现 业务 逻辑 ， 同 时 在 适当 的 时 
候 对 父 类 进行 细 化 。 








讲 了 这 么 多 ， 估 计 大 家 对 “倒置 ”这 个 词 还 是 有 点 不 理解 ， 那 到 底 什 
么 是 “倒置 ? 呢 ? 我 们 先 说 “ 正 置 ?是 什么 意思 ， 依 赖 正 置 就 是 类 间 的 依赖 
征 实 实在 在 的 实现 类 间 的 依赖 ， 也 惑 是 面 问 实现 编程 ， 这 也 是 正常 人 的 
思维 方式 ， 我 要 开 奔 驰 车 就 依赖 奔驰 车 ， 我 要 使 用 笔记 本 电脑 就 直接 依 
赖 笔记 本 电脑 ， 而 编写 程序 需要 的 是 对 现实 世界 的 事物 进行 抽象 ， 抽 和 象 














的 结果 就 是 有 了 抽象 类 和 接口 ， 然 后 我 们 根据 系统 设计 的 需要 产生 了 抽 
象 间 的 依赖 ， 代 蔡 了 人们 传统 忠 维 中 的 事物 间 的 依赖 ，“ 倒 置 * 束 是 从 这 
里 产生 的 。 


依赖 倒置 原则 的 优点 在 小 型 项 目 中 很 难 体现 出 来 ， 例 如 小 于 10 个 人 
月 的 项 目 ， 使 用 简单 的 SSH 染 构 ， 基 本 上 不 费 太 大 力气 就 可 以 完成 ， 是 
个 采用 依赖 倒置 原则 影响 不 大 。 但 是 ， 在 一 个 大 中 型 项 目 中 ， 采 用 依赖 
倒置 原则 有 非常 多 的 优点 ， 特 别 是 规避 一 些 非 技术 因素 引起 的 问题 。 项 
目 越 大 ， 需 求 变化 的 概率 也 武大， 通过 采用 依赖 倒置 原则 设计 的 接口 或 
抽象 类 对 实现 类 进行 约束 ， 可 以 减少 需求 变化 引起 的 工作 量 剧 增 的 情 
况 。 人 员 的 变动 在 大 中 型 项 目 中 也 是 时 常 存在 的 ， 如 果 设 计 优 民 、 代 码 
结构 清晰 ， 人 员 变 化 对 项 目的 影响 基本 为 零 。 大 中 型 项 目的 维护 周期 一 
般 都 很 长 ， 采 用 依赖 倒置 原则 可 以 让 维护 人 员 轻 松 地 扩展 和 维护 。 

















依赖 倒置 原则 是 6 个 设计 原则 中 最 难以 实现 的 原则 ， 它 是 实现 开 闭 
原则 的 重要 途径 ， 依 赖 倒置 原则 没有 实现 ， 就 别 想 实现 对 扩展 开放 ， 对 
修改 关闭 。 在 项 目 中 ， 大 家 只 要 记 住 是 “ 面 同 接 口 编程 * 束 基本 上 抓 住 了 
依赖 倒置 原则 的 核心 。 











讲 了 这 么 多 依赖 倒置 原则 的 优点 ， 我 们 也 来 打击 一 下 大 家 ， 在 现实 
世界 中 确实 存在 着 必须 依赖 细节 的 事物 ， 比 如 法 律 ， 就 必须 依赖 细 市 的 
定义 。“ 杀 人 偿命 ”在 中 国 的 法 律 中 古今 有 之 趾 ， 那 这 里 的 “杀人 ”就 是 一 
个 抽象 的 含义 ， 怎 么 杀 ， 杀 什么 人 ， 为 什么 杀人 ， 都 没有 定义 ， 只 要 是 








杀人 就 统统 得 偿命 ， 这 就 是 有 问题 了 ， 好 人 杀 了 坏人 ， 还 要 陪 上 目 己 的 
一 条 性 命 ， 这 是 不 公正 的 ， 从 这 一 点 看 ， 我 们 在 实际 的 项 目 中 使 用 依赖 
倒置 原则 时 需要 审时度势 ， 不 要 抓 住 一 个 原则 不 放 ， 每 一 个 原则 的 优点 
都 是 有 限度 的 ， 并 不 是 放 之 四 海 而 缘 准 的 真理 ， 所 以 别 为 了 章 循 一 个 原 
则 而 放弃 了 一 个 项 目的 终极 目标 : 投产 上 线 和 盘 利 。 作 为 一 个 项 目 经 理 
或 架构 师 ， 应 该 懂得 技术 只 是 实现 目的 的 工具 ， 攻 恼 了 顶 涉 上司， 设计 
做 得 再 漂 完 ， 代 码 写 得 再 完美 ， 项 目 做 得 再 符合 标准 ， 一 旦 项 目 亏本 ， 
产品 投入 大 于 产 出 ， 那 整体 就 是 扯淡 ! 你 自己 也 别 想 混 得 更 好 ! 





] 当年 汉 高 祖 刘 邦 入 关 后 与 老百姓 约法 三 章 ， 其 中 有 一 条 就 是 
者 死 ， 伤 人 及 盗 抵 罪 。 


当 
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第 4 章 ”接口 隔离 原则 


4.1 接口 隔离 原则 的 定义 





在 讲 接口 隔离 原则 之 前 ， 先 明确 一 下 我 们 的 主角 一 一 接口 。 接 口 分 
为 两 种 : 


e 实例 接口 (Object Interface) ， 在 Java 中 声明 一 个 类 ， 然 后 用 new 
关键 字 产 生 一 个 实例 ， 它 是 对 一 个 类 型 的 事物 的 描述 ， 这 是 一 种 接口 。 
比如 你 定义 Person 这 个 类 ， 然 后 使 用 Person zhangSan=new Person(0 产 生 
了 一 个 实例 ， 这 个 实例 要 遵从 的 标准 就 是 Person 这 个 类 ，Person 类 就 是 
zhangSan 的 接口 。 疑 惑 ? 看 不 懂 ? 不 要 紧 ， 那 是 因为 让 Java 语 言 浸 染 的 
时 间 太 长 了 ， 只 要 知道 从 这 个 角度 来 看 ，Java 中 的 类 也 是 一 种 接口 。 


e 类 接口 (Class Interface ) ，Java 中 经 常 使 用 的 interface 关 键 字 定义 
的 接口 。 


主角 已 经 定义 清楚 了 ， 那 什么 是 隔离 昵 ? 它 有 两 种 定义 ， 如 下 所 


e Clients should not be forced to depend upon interfaces that they don't 


use.〔 客 户 痢 不 应 该 依赖 它 不 需要 的 接口 。) 


e@ The dependency of one class to another one should depend on the 
smallest possible interface.〈 类 间 的 依赖 关系 应 该 建立 在 最 小 的 接口 
de 3 





新 事物 的 定义 一 般 都 比较 难 理解 ， 星 涩 难 懂 是正 常 的 。 我 们 把 这 两 
个 定义 放 析 一 下 ， 先 说 第 一 种 定义 : “ 客 忆 站 不 应 该 依赖 它 不 需要 的 接 
口 >， 那 依赖 什么 ?依赖 它 需 要 的 接口 ， 客 己 端 需要 什么 接口 就 提供 什 
么 接口 ， 把 不 需要 的 接口 剔除 反 ， 那 束 需 要 对 接口 进行 细 化 ， 保 证 其 纯 
洁 性 ， 再 看 第 二 种 定义 : “类 间 的 依赖 关系 应 该 建立 在 最 小 的 接口 上 ”， 
它 要求 是 最 小 的 接口 ， 也 是 要 求 接口 细 化 ， 接 口 纯洁 ， 与 第 一 个 定义 如 
出 一 略 ， 只 是 一 个 事物 的 两 种 不 同 描述 。 














我 们 可 以 把 这 两 个 定义 概括 为 一 句 话 : 建立 单一 接口 ， 不 要 建立 腔 
肿 庞大 的 接口 。 再 通俗 一 点 讲 : 接口 尽量 细 化 ， 同 时 接口 中 的 方法 尽量 
少 。 看 到 这 里 大 家 有 可 能 要 疑惑 了 ， 这 与 单一 职 贡 原则 不 是 相同 的 吗 ? 
错 ， 接 口 隔离 原则 与 单一 职责 的 审视 角度 是 不 相同 的 ， 单 一 职责 要 求 的 
古 类 和 接口 职 贡 单一 ， 注 重 的 是 职责 ， 这 是 业务 逻辑 上 的 划分 ， 而 接口 
隔离 原则 要 求 接口 的 方法 尽量 少 。 例 如 一 个 接口 的 职责 可 能 包含 10 个 方 
法 ， 这 10 个 方法 都 放 在 一 个 接口 中 ， 并 且 提 供给 多 个 模块 访问 ， 各 个 模 
块 按照 规定 的 权限 来 访问 ， 在 系统 外 通过 文档 约束 “不 使 用 的 方法 不 要 
访问 ”， 按 照 单一 职责 原则 是 允许 的 ， 按 照 接口 隔离 原则 是 不 允许 的 ， 
因为 它 要 求 “ 尽 量 使 用 多 个 专门 的 接口 ?。 专 门 的 接口 指 什么 ?就 是 指 提 


























供给 每 个 模块 的 都 应 该 是 单一 接口 ， 提 供给 几 个 模块 就 应 该 有 几 个 接 
口 ， 而 不 是 建立 一 个 庞大 的 胱 肿 的 接口 ， 容 纳 所 有 的 客户 站 访问 。 


4.2 美女 何其 多 ， 观 点 各 不 同 





我 们 举例 来 说 明 接 口 隔离 原则 到 撒 对 我 们 提出 了 什么 有 要求。 现在 男 
生 对 小 姑 奶 的 称呼 ， 使 用 频率 最 高 的 应 该 是 “美女 ”了 吧 ， 你 在 大 街 上 叫 
一 声 :“ 了 蜂 ， 美 女 ! ”估计 10 个 有 8 个 回 兴 ， 其 中 包括 那 位 着 名 的 如 论 。 











美女 的 标准 各 不 相同 ， 首 先 就 需要 定义 一 下 什么 是 美女 :首先 要 面貌 好 
看 ， 其 次 是 身材 要 穷 完 ， 然 后 要 有 气质 ， 当 然 了 ， 这 三 者 各 人 的 排列 顺 
序 不 一 样 ， 总 之 要 成 为 一 名 美女 就 必须 具备 ， 面 狐 、 身 材 和 气质 ， 我 们 
用 类 图 体现 一 下 星 探 (当然 ， 你 也 可 以 把 自己 想象 成 星 探 ， 找 美女 的 过 
程 ， 如 图 4-1 所 示 。 


AbstractSearcher <<mterface>> 
IPettyGirl 


+AbstractSearcher(IPettyQirl _pettyGil) 


+vold goodLooking() 

+vold niceFigure() 

+void ereatTemperament() 
人 
a 


tHapbstract void show!() 











图 4-1 星 探 寻找 美女 的 类 图 


定义 了 一 个 IPettyGirl 接 口 ， 声 明 所 有 的 美女 都 应 该 有 
goodLooking、niceFigure 和 great-Temperament， 然 后 义 定义 了 一 个 抽象 


类 AbstractSearcher， 其 作用 就 是 搜索 美女 并 显示 其 信息 ， 只 要 美女 都 按 
照 这 个 规范 定义 ，Searcher( 星 探 ) 束 轻松 多 了 ， 美 女 类 的 实现 如 代码 
清单 4-1 所 示 。 





代码 清单 4-1 美女 类 


public interface IPettyGirl { 
// 要 有 婉 好 的 面孔 
public void goodLooking(); 
有 好 身材 
public void niceFigure(); 
// 要 有 气质 
public void greatTemperament ( ) ; 


~ 
~ 
烛 








美女 的 标准 定义 完毕 ， 具 体 的 美女 实现 类 如 代码 清单 4-2 所 示 。 


代码 清单 4-2 美女 实现 类 


public class PettyGirl implements IPettyGirl { 
private String name; 
// 美 女 都 有 名 字 
public PettyGirl(String _name)t{ 
this.name=_name; 























} 

// 脸 和 蛋 漂亮 

public void goodLooking() { 
System.out.println(this.name + "--- 脸 和 蛋 很 漂亮 1")，; 

} 

// 气 质 要 好 

public void greatTemperament() { 
System,out.println(this.name + "--- 气 质 非常 好 !")，; 

} 

// 壬 材 要 好 

public void niceFigure() { 
System.out.println(this.name + "--- 身 材 非 常 棒 !")， 

} 


通过 三 个 方法 ， 把 对 美女 的 要 求 都 定义 出 来 了 ， 按 照 这 个 标准 ， 如 
花 寻 女 被 排除 在 美女 标准 之 外 了 。 有 美女 ， 就 有 搜索 美女 的 星 探 ， 其 具 
体 实 现 如 代码 清单 4-3 所 示 。 


代码 清单 4-3 星 探 抽象 类 源 代码 


public abstract class AbstractSearcher { 
protected IPettyGirl pettyGirl; 
public AbstractSearcher(IPettyGirl _pettyGirl){ 
this.pettyGirl = _pettyGirl]l; 


} 
// 搜 索 美 女 ， 列 出 美女 信息 


public abstract void show( ); 





星 探 的 实现 类 就 比较 简单 了 ， 其 源 代 码 如 代码 清单 4-4 所 示 。 


代码 清单 4-4 星 探 类 


public class Searcher extends AbstractSearchert{ 
public Searcher(IPettyGirl _pettyGirl1)t{ 
super(_pettyGirl); 


} 
// 展 示 美 女 的 信息 
public void show( ){ 
System,out,.println("-------- 美女 的 信息 如 下 : ----------- 
// 展 示 面 容 
super .pettyGirl.goodLooking( ) ; 
// 展 示 身 材 
super .pettyGirl.niceFigure(); 
// 展 示 气 质 
Super .pettyGir1L.greatTemperament ( ) 











场景 中 的 两 个 角色 美女 和 星 探 都 已 经 出 现 了 ， 需 要 写 一 个 场景 类 来 
串联 起 各 个 角色 ， 场 景 类 的 实现 如 代码 清单 4-5 所 示 。 


代码 清单 4-5 场景 类 


public class Client { 
// 搜 索 并 展示 美女 信息 
public static void main(String[] args) { 
// 定 义 一 个 美女 
IPettyGirl yanYan = new PettyGir1(" 嫣 婚 " ) 
AbstractSearcher searcher = new Searcher(yanYan ) ; 
Searcher ,show( ) ; 











星 探 搜 索 美 女 的 运行 结果 如 下 所 示 : 





ee 美女 的 信息 如 下 ------------- 


婚 嫣 --- 脸 蛋 很 漂亮 ! 











婚 婚 --- 喘 材 非 常 棒 ! 





婚 嫂 -气质 非常 好 ! 





星 探寻 找 美女 的 程序 开发 完毕 了 ， 运 行 结果 也 正确 。 我 们 回头 来 想 
想 这 个 程序 有 没有 问题 ， 思 考 一 下 IPettyGirl 这 个 接口 ， 这 个 接口 是 否 做 
到 了 最 优化 设计 ? 答案 是 没有 ， 还 可 以 对 接口 进行 优化 。 





我 们 的 审美 观点 都 在 改变 ， 美 女 的 定义 也 在 变化 。 唐 朝 的 杨 贵 妃 如 
果 活 在 现在 这 个 年 代 非 铸 愧 而 死 不 可 ， 为 什么 ? 胖 呀 ! 但 是 胖 并 不 影 啊 
她 入 选中 国 四 大 美女 ， 说 明 当 时 的 审美 观 与 现在 是 有 差异 的 。 当 然 ， 随 
者 时 代 的 发 展 我 们 的 审美 观 也 在 变化 ， 当 你 发 现 有 一 个 女孩 ， 脸 和 皇 不 怎 
么 样 ， 里 材 也 一 般 般 ， 但 是 气质 非常 好 ， 我 相信 大 部 分 人 都 会 把 这 样 的 
女孩 叫 美女 ， 审 美 素质 提升 了 ， 束 产生 了 气质 型 美女 ， 但 是 我 们 的 接口 








却 定义 了 美女 必须 是 三 者 都 具备 ， 按 照 这 个 标准 ， 气 质 型 美女 就 不 能 
美女 ， 那 怎么 办 ? 可 能 你 要 说 了 ， 我 重新 扩展 一 个 美女 类 ， 只 实现 
greatTemperament 方 法 ， 其 他 两 个 方法 置 空 ， 什 么 都 不 号 ， 不 就 可 以 了 
吗 ? 聪明 ， 但 是 行 不 通 ! 为 什么 昵 ? 星 探 AbstractSearcher 依 赖 的 是 
IPettyGirl 接 口 ， 它 有 三 个 方法 ， 你 只 实现 了 两 个 方法 ， 星 探 的 方法 是 不 
是 要 修改 ? 我 们 上 面 的 程序 打印 出 来 的 信息 少 了 两 条 ， 还 让 星 探 怎么 去 
辨别 是 不 是 美女 呢 ? 




















分 析 到 这 里 ， 我 们 发 现 接 口 IPettyGin 的 设计 是 有 缺陷 的 ， 过 于 庞大 
了 ， 容 纳 了 一 些 可 变 的 因素 ， 根 据 接口 隔离 原则 ， 星 探 AbstractSearcher 
应 该 依赖 于 具有 部 分 特质 的 女孩 子 ， 而 我 们 却 把 这 些 特质 都 封装 了 起 
来 ， 放 到 了 一 个 接口 中 ， 封 装 过 度 了 ! 问题 找到 了 ， 我 们 重新 设计 一 下 
类 图 ， 修 改 后 的 类 图 如 图 4-2 所 示 。 











把 原 IPettyGirl 接 口 拆 分 为 两 个 接口 ， 一 种 是 外 形 美的 美女 
IGoodBodyGirll， 这 类 美女 的 特点 束 是 脸 重 和 里 材 极 棒 ， 超 一 流 ， 但 是 
没有 审美 素质 ， 比 如 随地 吐 痰 ， 文 化 程度 比较 低 ， 另外 一 种 是 气质 美的 
美女 IGreatTemperamentGirl， 谈 吐 和 修养 都 非常 高 。 我 们 把 一 个 比较 腾 
肿 的 接口 拆 分 成 了 两 个 专门 的 接口 ， 灵 活性 提高 了 ， 可 维护 性 也 增加 
了 ， 不 管 以 后 是 要 外 形 美 的 美女 还 是 气质 美的 美女 都 可 以 轻松 地 通过 
PettyGirl 定 义 。 两 种 类 型 的 美女 定义 如 代码 清单 4-6 所 示 。 











AbstractSearcher 


tAbstractSearcher(IGreatTemperamentGirl gretTemperamentGirl)) | 
tHAbstractSearcher(IGoodBodyGir] _goodBodyGir]l) 


tabstract void show() 












Searcher 







中 





<=<interface>> 


IGoodBodyGirl 


=<nterface>> 
IGreatTemperamentGirl 









+vold goodLookme() 
+vold niceFieure() 


NO 


t+vold greatTemperament() 








图 4-2 修改 后 的 星 探 寻找 美女 类 图 


代码 清单 4-6 两 种 类 型 的 美女 定义 


public interface IGoodBodyGirl { 
// 要 有 婉 好 的 面孔 
public void goodLooking(); 
// 要 有 好 身材 


public void niceFigure(); 





public interface IGreatTemperamentGirl { 
// 要 有 气质 
public void greatTemperament ( ) ; 





按照 脸蛋 、 身 材 、 和 气质 都 具备 才 算 美女 ， 实 现 类 实现 两 个 接口 ， 如 
代码 清单 4-7 所 示 。 
代码 清单 4-7 最 标准 的 美女 


public class PettyGirl implements IGoodBodyGir]l,IGreatTemperament 
private String name; 


// 美 女 都 有 名 字 
public PettyGirl(String _name)t{ 
this.name=_name; 























// 脸 蛋 漂亮 

public void goodLooking() { 
System.out.println(this.name + "--- 脸 蛋 很 漂亮 1")，; 

} 

// 气 质 要 好 

public void greatTemperament() { 
System.out.println(this.name + "--- 气 质 非常 好 !")，; 

} 

// 壬 材 要 好 

public void niceFigure() { 
System.out,println(this,name + "--- 身 材 非常 棒 !"); 

} 








通过 这 样 的 重 构 以 后 ， 不 管 以 后 是 要 气质 美女 还 是 要 外 形 美 女 ， 部 
可 以 保持 接口 的 稳定 。 当 然 ， 你 可 能 要 说 了， 以 后 可 能 审美 观点 再 发 生 
改变 ， 只 有 脸 香 好 看 就 是 美女 ， 那 这 个 IGoodBody 接 口 还 是 要 修改 的 
呀 ， 确 实 是 ， 但 是 设计 是 有 限度 的 ， 不 能 无 限 地 考虑 未 来 的 变更 情况 ， 
人 否则 就 会 陷入 设计 的 泥潭 中 而 不 能 自拔 。 








以 上 把 一 个 及 和 肿 的 接口 变更 为 两 个 独立 的 接口 所 依赖 的 原则 就 是 接 
口 隔离 原则 ， 让 星 探 AbstractSearcher 依 赖 两 个 专用 的 接口 比 依赖 一 个 综 
合 的 接口 要 灵活 。 接 口 是 我 们 设计 时 对 外 提供 的 契约 ， 通 过 分 散 定义 多 
个 接口 ， 可 以 预防 未 来 变更 的 扩散 ， 提 高 系统 的 灵活 性 和 可 维护 性 。 


4.3 保证 接口 的 纯洁 性 








接口 隔离 原则 是 对 接口 进行 规范 约束 ， 其 包含 以 下 4 层 含义 : 


e 接口 要 尽量 小 





这 是 接口 隔离 原则 的 核心 定义 ， 不 出 现 胱 肿 的 接口 (Fat 
Iterface) ， 但 是 “小 ?是 有 限度 的 ， 首 先 就 是 不 能 违反 单一 职责 原则 ， 
什么 意思 呢 ? 我 们 在 单一 职责 原则 中 提 到 一 个 IPhone 的 例子 ， 在 这 里 ， 
我 们 使 用 单一 职 贡 原则 把 两 个 职责 分解 到 两 个 接口 中 ， 类 图 如 图 4-3 所 


人 钞 。 


<<interface>> <<Imterface>> 


IConnectionManager IDataTransfer 
Ee==== = = 二 = 


+void dial(String phone Number) +DataTransfer(IConnectionManager cm) 
Hvoid huangup() +vold chat(Object o) 


tvold answer(Object o) 









ConnectionManager 








图 4-3 电话 类 图 





仔细 分 析 一 下 IConnectionManager 接 口 是 否 还 可 以 再 继续 拆 分 下 


去 ， 挂 电话 有 两 种 方式 : 一 种 是 正常 的 电话 挂 断 ， 一 种 是 电话 异常 挂 

机 ， 比 如 突然 没 电 了 ， 通 信 当 然 就 断 了 。 这 两 种 方式 的 处 理应 该 是 不 同 
的 ， 为 什么 呢 ? 正 千 挂 电话 ， 对 方 接受 到 挂机 信号 ， 计 费 系 统 也 瓯 停止 
计 费 了 ， 那 手机 没 电 了 这 种 方式 束 不 同 了 ， 它 是 信 写 丢失 了 ， 中 继 服 务 
器 检查 到 了 ， 然 后 通知 计 费 系统 停止 计 费 ， 否 则 你 的 费用 不 是 要 疯狂 地 
增长 了 吗 ? 








思考 到 这 里 ， 我 们 是 不 是 就 要 动手 把 IConnectionManager 接 口 拆 封 
成 两 个 ， 一 个 接口 是 负责 连接 ， 一 个 接口 是 负责 挂 电话 ? 是 要 这 样 做 
吗 ? 且慢 ， 让 我 们 再 思考 一 下 ， 如 果 拆 分 了 ， 那 就 不 符合 单一 职责 原则 
了 ， 因 为 从 业务 逻辑 上 来 讲 ， 通 信 的 建立 和 关闭 已 经 是 最 小 的 业务 单位 
了 ， 再 细 分 下 去 就 是 对 业务 或 是 协议 《其 他 业务 馆 辑 ) 的 拆 分 了 。 想 想 
看 ， 一 个 电话 要 关心 3G 协 议 ， 要 考虑 中 继 服务 器 ， 等 等 ， 这 个 电话 还 
怎么 设计 得 出 来 呢 ? 从 业务 层次 来 看 ， 这 样 的 设计 就 是 一 个 失败 的 设 
计 。 一 个 原则 要 拆 ， 一 个 原则 又 不 要 拆 ， 那 该 怎么 办 ? 好 办 ， 根 据 接 口 
隔离 原则 拆 分 接口 时 ， 首 先 必 须 满足 单一 职责 原则 。 





e 接口 要 高 内 聚 





什么 是 高 内 聚 ? 高 内 聚 就 是 提高 接口 、 类 、 模 块 的 处 理 能 力 ， 减 少 
对 外 的 交互 。 比 如 你 告诉 下 属 “ 到 奥巴马 的 办 公 室 偷 一 个 xxx 文 件 ”， 然 
后 听 到 下 属 用 坚定 的 口吻 回答 你 :“ 是 ， 保 证 完成 任务 ! ”一 个 月 后 ， 你 
的 下 属 还 真 的 把 xxx 文 件 放 到 你 的 办 公 果 上 了 ， 这 种 不 讲 任 何 条 件 、 立 











刻 完成 任务 的 行为 承 是 高 内 聚 的 表现 。 有 具体 到 接口 隔离 原则 就 是 ， 要 求 
在 接口 中 尽量 少 公 布 public 方 法 ， 接 口 是 对 外 的 承 诡 ， 承 诡 越 少 对 系统 
的 开发 越 有 利 ， 变 更 的 风险 也 就 越 少 ， 同 时 也 有 利于 降低 成 本 。 


e 定制 服务 


一 个 系统 或 系统 内 的 模块 之 间 必 然 会 有 厢 合 ， 有 和 灯 合 就 要 有 相互 访 
问 的 接口 (并 不 一 定 束 是 Java 中 定义 的 Interface， 也 可 能 古 一 个 类 或 单 
纯 的 数据 交换 ) ， 我 们 设计 时 就 需要 为 各 个 访问 者 ( 即 客 尸首) 定制 服 
务 ， 什 么 是 定制 服务 ?定制 服务 就 是 单独 为 一 个 个 体 提供 优 民 的 服务 。 
我 们 在 做 系统 设计 时 也 需要 考虑 对 系统 之 间或 模块 之 间 的 接口 采用 定制 
服务 。 采 用 定制 服务 束 必 然 有 一 个 要 求 : 只 提供 访问 者 需要 的 方法 ， 这 
是 什么 意思 ? 我 们 举 个 例子 来 说 明 ， 比 如 我 们 开发 了 一 个 图 书 管理 系 
统 ， 其 中 有 一 个 碍 询 接口 ， 方 便 管 理 员 查询 图 书 ， 其 类 图 如 图 4-4 所 


<<interface>> 
IBookSearcher 
| | 
+vold searchByAuthor() 














让 
了 
O 


+void searchByTitle() 

+void searchByPublisher() 

+vold searchByCatagory() 
+vold complexSearch(Map map) 





图 4-4 图 书 查 询 类 图 





在 接口 中 定义 了 多 个 碍 询 方法 ， 分 别 可 以 按照 作者 、 标 题 、 出 版 
社 、 分 类 进行 查询 ， 最 后 还 提供 了 混合 查询 方式 。 程 序 写 好 了 ， 投 产 上 
线 了 ， 突 然 有 一 天 发 现 系统 速度 非常 慢 ， 然 后 就 开始 痛 兰 地 分 析 ， 了 最 终 
发 现 是 访问 接口 中 的 complexSearch(Map map) 方 法 并 发 量 太 大 ， 导 致 应 
用 服务 器 性 能 下 降 ， 然 后 继续 跟踪 下 去 及 现 这 些 碍 询 都 是 从 公 网 上 发 起 
的 ， 进 一 步 分 析 ， 找 到 问题 ， 提 供给 公 网 ( 公 网 项 目 是 力 外 一 个 项 目 组 
开发 的 ) 的 碍 询 接口 和 提供 给 系统 内 管理 人 员 的 接口 是 相同 的 ， 都 是 
IBookSearcher 接 口 ， 但 是 权限 不 同 ， 系 统管 理 人 员 可 以 通过 接口 的 
complexSearch 方 法 碍 询 到 所 有 的 书籍 ， 而 公 网 的 这 个 方法 是 被 限制 的 ， 
不 返回 任何 值 ， 在 设计 时 通过 口头 约束 ， 这 个 方法 是 不 可 被 调用 的 ， 但 
征 由 于 公 网 项 目 组 的 疏忽 ， 这 个 方法 还 是 公布 了 出 去 ， 虽 然 不 能 返回 结 
果 ， 但 是 还 是 引起 了 应 用 服务 器 的 性 能 巨 慢 的 情况 发 生 ， 这 就 是 一 个 腾 
肿 接口 引起 性 能 故障 的 案例 。 


























问题 找到 了 ， 就 需要 把 这 个 接口 进行 重 构 ， 将 IBookSearcher 拆 分 为 
两 个 接口 ， 分 别 为 两 个 模块 提供 定制 服务 ， 修 改 后 的 类 图 如 图 4-5 所 


钞 。 


<<mterface>> <<Interface>> 
ISimple BookSearcher IComplexBookSearcher 


+vold searchByAuthor() +vold complexSearch(Map map 
+vold searchByTitle() 

+vold searchByPublisher() 

Hvoid searchByCatagory() 





图 4-5 修改 后 的 图 书 查 询 类 图 


提供 给 管理 人 员 的 实现 类 同时 实现 了 ISimpleBookSearcher 和 
IComplexBookSearcher 两 个 接口 ， 原 有 程序 不 用 做 任何 改变 ， 而 提供 给 
公 网 的 接口 变 为 I SimpleBookSearcher， 只 人 允许 进行 简单 的 查询 ， 单 独 为 
其 定制 服务 ， 减 少 可 能 引起 的 风险 。 





e 接口 设计 是 有 限度 的 





接口 的 设计 粒度 越 小 ， 系 统 越 灵 活 ， 这 是 不 和 争 的 事实 。 但 是 ， 灵 活 
的 同时 也 带 来 了 结构 的 复杂 化 ， 开 发 难度 增加 ， 可 维护 性 降低 ， 这 不 是 
一 个 项 目 或 产品 所 期 望 看 到 的 ， 所 以 接口 设计 一 定 要 注意 适度 ， 这 
个 “ 度 ” 如 何 来 判断 呢 ? 根据 经 验 和 常识 判断 ， 没 有 一 个 固化 或 可 测量 的 
标准 。 








4.4 最 佳 实践 








接口 隔离 原则 是 对 接口 的 定义 ， 同 时 也 是 对 类 的 定义 ， 接 口 和 类 尺 
量 使 用 原子 接口 或 原子 类 来 组 装 。 但 是 ， 这 个 原子 该 怎么 划分 是 设计 模 
式 中 的 一 大 难题 ， 在 实践 中 可 以 根据 以 下 几 个 规则 来 衡量 : 








。 一 个 接口 只 服务 于 一 个 子 模块 或 业务 逻辑 ; 


e 通过 业务 逻辑 压缩 接口 中 的 public 方 法 ， 接 口 时 常 去 回顾 ， 尽 量 
让 接口 达到 “满员 筋骨 肉 "， 而 不 是 “ 肥 嘟 嘟 ”的 一 大 堆 方 法 ; 





e 已 经 被 污染 了 的 接口 ， 尽 量 去 修改 ， 奉 变更 的 风险 较 大 ， 则 采用 
适配器 模式 进行 转化 处 理 ; 





e 了 解 环境 ， 拒 绝 下 从。 每 个 项 目 或 产品 都 有 特定 的 环境 因素 ， 别 
看 到 大 师 是 这 样 做 的 你 就 照抄 。 千 万 别 ， 环 境 不 同 ， 接 口 拆 分 的 标准 束 
不 同 。 深 入 了 解 业务 馆 辑 ， 最 好 的 接口 设计 就 出 目 你 的 手中 ! 














接口 隅 离 原 则 和 其 他 设计 原则 一 样 ， 都 需要 人 花费 较 多 的 时 间 和 精力 
来 进行 设计 和 筹划 ， 但 是 它 带 来 了 设计 的 灵活 性 ， 让 你 可 以 在 业务 人 员 
提出 “无 理 ” 要 求 时 轻松 应 付 。 贯 彻 使 用 接口 隔离 原则 最 好 的 方法 就 是 一 
个 接口 一 个 方法 ， 保 证 绝对 符合 接口 隔离 原则 (有 可 能 不 符合 单一 职责 
原则 ) ， 但 你 会 采用 吗 ? 不 会 ， 除 非 你 是 狗 子 ! 那 怎 么 才能 正确 地 使 用 

















接口 隔离 原则 呢 ? 答案 是 根据 经 验 和 和 常识 决定 接口 的 粒度 大 小 ， 接 口 粒 
度 太 小 ， 导 致 接口 数据 剧 增 ， 开 发 人 员 哗 死 在 接口 的 海洋 里 ， 接口 粒度 
太 大 ， 灵 活性 降低 ， 无 法 提供 定制 服务 ， 给 整体 项 目 带 来 无 法 预料 的 风 


险 。 





怎么 准确 地 实践 接口 隔离 原 则 ? 实践 、 经 验 和 领悟 ! 


往生 


第 5 草 ” 迪 米 特 法 则 


5.1 迪 米 特 法 则 的 定义 


迪 米 特 法 则 (Law of Demeter，LoD ) 也 称 为 最 少 知识 原则 (Least 
Knowledge Principle，LKP) ， 虽 然 名 字 不 同 ， 但 描述 的 是 同一 个 规 
则 : 一 个 对 象 应 该 对 其 他 对 象 有 最 少 的 了 解 。 通 俗 地 讲 ， 一 个 类 应 该 对 
自己 需要 灰 合 或 调用 的 类 知道 得 最 少 ， 你 《被 耦合 或 调用 的 类 ) 的 内 部 
是 如 何 复杂 都 和 我 没关系 ， 那 是 你 的 事情 ， 我 就 知道 你 提供 的 这 么 多 
public 方 法 ， 我 就 调用 这 么 多 ， 其 他 的 我 一 概 不 关心 。 


一 ”~ 一 


5.2 我 的 知识 你 知道 得 越 少 越 好 


迪 米 特 法 则 对 类 的 低 耦 合 提出 了 明确 的 要 求 ， 其 包含 以 下 4 层 合 


1. 只 和 朋友 交流 


迪 米 特 法 则 还 有 一 个 英文 解释 是 : Only talk to your immediate 
friends (只 与 直接 的 朋友 通信 。) 什么 叫做 直接 的 朋友 呢 ? 每 个 对 象 都 
必然 会 与 其 他 对 象 有 耦合 关系 ， 两 个 对 象 之 间 的 耦合 就 成 为 朋友 关系 ， 
这 种 关系 的 类 型 有 很 多 ， 例 如 组 合 、 聚 合 、 依 赖 等 。 下 面 我 们 将 举例 说 
明 如 何 才 能 做 到 只 与 直接 的 朋友 交流 。 


传说 中 有 这 样 一 个 故事 ， 老 师 想 让 体育 委员 确认 一 下 全 班 女 生来 齐 
没有 ， 就 对 他 说 :“ 你 去 把 全 班 女 生 清 一 下 。” 体 育 委 员 没 听 清 楚 ， 就 问 
道 :“ 呀 ，.……. 那 亲 哪个 ? ”老师 无 语 了 ， 我 们 来 看 这 个 笑话 怎么 用 程序 
来 实现 ， 类 图 如 图 5-1 所 示 。 





EE =- 证 


Hvold commond(GroupLeader groupLeader) 


GroupLeader 


= 一 一 一 一 = 一 ss 
+vold countGirls(List<Girl> listGirls) 





图 5-1 老师 要 求 清点 女生 类 图 


Teacher 类 的 commond 方 法 负责 发 送 命令 给 体育 委员 ， 命 令 他 清点 


女生 ， 其 实现 过 程 如 代码 清单 5-1 所 示 。 


代码 清单 5-1 老师 类 


public class Teacher 
// 老 师 对 学 生发 布 命令 ， 清 一 下 女生 
public void commond(GroupLeader groupLeader){ 
List listGirls = new ArrayList(); 
// 初 始 化 女生 
for(int i=0;i<20;i++){ 
listGirls.add(new Girl1()); 


} 
// 告 诉 体育 委员 开始 执行 清查 任务 


groupLeader .countGirls(1istGirls); 


老师 只 有 一 个 方法 commond， 先 定义 出 所 有 的 女生 ， 然 后 发 布 命令 
给 体育 委员 ， 云 清点 一 下 女生 的 数量 。 体 育 委 员 GroupLeader 的 实现 过 
程 如 代码 清单 5-2 所 示 。 





代码 清单 5-2 体育 委员 类 实现 过 程 


public class GroupLeader { 
// 清 查 女 生 数量 
public void countGirls(List<Girl> listGirls)t{ 
System.out.println(" 女 生 数 量 是 : "+1listGirls.size()); 
} 











老师 类 和 体育 委员 类 部 对 女生 类 产生 依赖 ， 而 且 女 生 类 不 需要 执行 
任何 动作 ， 因 此 定义 一 个 空 类 ， 其 实现 过 程 如 代码 清单 5-3 所 示 。 


代码 清单 5-3 女生 类 


public class Girl { 
} 





故事 中 的 三 个 角色 都 已 经 有 了 ， 再 定义 一 个 场景 类 来 插 述 这 个 故 
事 ， 其 实现 过 程 如 代码 清单 5-4 所 示 。 


代码 清单 5-4 场景 类 


public class Client { 
public static void main(String[|] args) { 
Teacher teacher= new Teacher(); 
// 老 师 发 布 命令 


teacher ,commond(new GroupLeader() ) ; 


-一 


运行 结果 如 下 所 示 : 


女生 数量 是 : 20 








体育 委员 按照 老师 的 要 求 对 女生 进行 了 清点 ， 并 得 出 了 数量 。 我 们 


回 过 头 来 思考 一 下 这 个 程序 有 什么 问题 ， 首 先 确 定 Teacher 类 有 几 个 朋 
友 类 ， 它 仅 有 一 个 朋友 类 GroupLeader。 为 什么 Gin 不 是 朋友 类 呢 ? 
Teacher 也 对 它 产生 了 依赖 关系 呀 ! 朋友 类 的 定义 是 这 样 的 : 出 现在 成 
员 变 量 、 方 法 的 输入 输出 参数 中 的 类 称 为 成 员 朋 友 类 ， 而 出 现在 方法 体 
内 部 的 类 不 属于 朋友 类 ， 而 Girl 这 个 类 就 是 出 现在 commond 方 法 体内 ， 
因此 不 属于 Teacher 类 的 朋友 类 。 迪 米 特 法 则 告诉 我 们 一 个 类 只 和 朋友 
类 交流 ， 但 是 我 们 刚刚 定义 的 commond 方 法 却 与 Gil 类 有 了 交流 ， 声 明 
了 一 个 List<Girls> 动 态 数组 ， 也 就 是 与 一 个 陌生 的 类 Gi 有 了 交流 ， 这 
样 就 破坏 了 Teacher 的 健壮 性 。 方 法 是 类 的 一 个 行为 ， 类 竟然 不 知道 自 
己 的 行为 与 其 他 类 产生 依赖 关系 ， 这 是 不 允许 的 ， 严 重 违反 了 迪 米 特 法 
则 。 

















问题 已 经 发 现 ， 我 们 修改 一 下 程序 ， 将 类 图 稍 作 修改 ， 如 图 5-2 所 


dl 


PC 一 





ivoid commond(GroupLeader groupLeader) 


GroupLeader 






+GroupLeader(List<Grl> tstGtrls) 


+void countGtrls( ) 


图 5-2 修改 后 的 类 图 


在 类 图 中 去 掉 Teacher 对 Gil 类 的 依赖 和 关系， 修改 后 的 Teacher 类 
码 清单 5-5 所 示 。 


代码 清单 5-5 修改 后 的 老师 类 


public class Teacher 区 
// 老 师 对 学 生发 布 命 令 ， 清 一 下 女生 
public void commond(GroupLeader groupLeader ){ 
// 告 诉 体育 委员 开始 执行 清查 任务 


groupLeader .countGirls(); 


修改 后 的 GroupLeader 类 如 代码 清 代 5-6 所 示 。 


代码 清单 5-6 修改 后 的 体育 委员 类 


public class GroupLeader { 
private List<Girl> listGirls; 
// 传 递 全 班 的 女生 进来 
public GroupLeader(List<Girl> _listGirls)t{ 
this.1listGirls = _listGirls; 


} 
// 清 但 女生 数量 
public void countGirls(){ 








如 代 


System.out.println(" 女 生 数 量 是 : "+this.1listGirls.size( 





} 


在 GroupLeader 类 中 定义 了 一 个 构造 函数 ， 通 过 构造 函数 传递 了 依 





赖 天 系 。 同 时 ， 对 场景 类 也 进行 了 一 些 修改 ， 如 代码 清单 5-7 所 示 。 


代码 清单 5-7 修改 后 的 场景 类 


public class Client { 
public static void main(String[] args) { 
// 产 生 一 个 女生 群体 
List<Girl> listGirls = new ArrayList<Gir1l>(); 


// 初 始 化 女生 

for(int i=0;i<20;i++){ 
listGirls.add(new Gir1()); 

Teacher Loe new Teacher(); 


// 老 师 发 布 命令 


teacher ,commond(new GroupLeader (1listGirls)); 


对 程序 进行 了 简单 的 修改 ， 把 Teacher 中 对 List<Girl> 的 初始 化 移动 
到 了 场景 类 中 ， 同 时 在 GroupLeader 中 增加 了 对 Girl 的 注入 ， 避 开 了 
Teacher 类 对 陌生 类 Gin 的 访问 ， 降 低 了 系统 间 的 耦合 ， 提 高 了 系统 的 健 
壮 性 。 








注意 “一 个 类 只 和 朋友 交流 ， 不 与 陌生 类 交流 ， 不 要 出 现 
getA0.getB0.getC0O.getDO 这 种 情况 《在 一 种 极端 的 情况 下 允许 出 现 这 种 
访问 ， 即 每 一 个 点 号 后 面 的 返回 类 型 都 相同 ) ， 类 与 类 之 间 的 关系 是 建 
立 在 类 间 的 ， 而 不 是 方法 间 ， 因 此 一 个 方法 尽量 不 引入 一 个 类 中 不 存在 
的 对 象 ， 当 然 ，JDK API 提 供 的 类 除外 。 











2. 朋友 间 也 是 有 距离 的 





人 和 人 之 间 是 有 距离 的 ， 太 远 关 系 逐 渐 琉 远 ， 最 终 形 同 陌 路， 太 近 
就 相互 刺 伤 。 对 朋友 关系 描述 最 贴切 的 故事 就 是 : 两 只 刺 猜 取 上 暖 ， 太 远 





取 不 到 上 暖 ， 太 近 刺 伤 了 对 方 ， 必 须 保持 一 个 既 能 取暖 又 不 刺 伤 对 方 的 距 
离 。 迪 米 特 法 则 就 是 对 这 个 距离 进行 描述 ， 即 使 是 朋友 类 之 间 也 不 能 
话 不 说 ， 无 所 不 知 。 


我 们 在 安装 软件 的 时 候 ， 经 常会 有 一 个 导 同 动作 ， 第 一 步 是 确认 是 
合 安 装 ， 第 二 步 确 认 License， 再 然后 选择 安装 目录 ..….... 这 是 一 个 典型 的 
顺序 执行 动作 ， 有 具体 到 程序 中 就 是 : 调用 一 个 或 多 个 类 ， 先 执行 第 一 个 
方法 ， 然 后 是 第 二 个 方法 ， 根 据 返 回 结果 再 来 看 是 否 可 以 调用 第 三 个 方 
法 ， 或 者 第 四 个 方法 ， 等 等 ， 其 类 图 如 图 5-3 所 示 。 


InstallSoftware Wizard 





+void mstallWizard( Wizard wizard) +int first() 
+int second() 
+int third() 





图 5-3 软件 安装 过 程 类 图 





很 简单 的 类 图 ， 实 现 软件 安装 的 过 程 ， 其 中 first 方 法 定义 第 一 步 做 
什么 ，second 方 法 定义 第 二 步 做 什么 ，third 方 法 定义 第 三 步 做 什么 ， 其 
实现 过 程 如 代码 清单 5-8 所 示 。 


代码 清单 5-8 导向 类 


public class Wizard { 
private Random rand = new Random(System.currentTimeMillis()) 
// 第 一 步 


public int first(){ 
System.out.printLn(" 执 行 第 一 个 方法 ...")， 
return rand ,nextInt(100 ) ; 





} 

// 第 二 步 

public int second(){ 
System.out .println(" 执 行 第 二 个 方法 ..."); 
return rand.nextInt(100); 








} 

// 第 三 个 方法 

public int third()t{ 
System.out.printlin(" 执 行 第 三 个 方法 ,..")} 
return rand.nextInt(100); 





在 Wizard 类 中 分 别 定义 了 三 个 步骤 方法 ， 每 个 步骤 中 都 有 相关 的 业 
务 逻 辑 完成 指定 的 任务 ， 我 们 使 用 一 个 随机 函数 来 代 蔡 业务 执行 的 返回 
值 。 软 件 安装 InstallSoftware 类 如 代码 清单 5-9 所 示 。 


代码 清单 5-9 InstallSoftware 类 


public class InstallSoftware { 
public void installwWizard(Wizard wizard)t{ 
int first = wizard.first(); 
// 根 据 first 返 回 的 结果 ， 看 是 否 需 要 执行 Second 








If(first>50){ 
int second = wizard.second(); 
if(second>50)t{ 
int third = wizard.third(); 
if(third >50){ 
wizard.first(); 
} 
} 
} 


根据 每 个 方法 执行 的 结果 决定 是 否 继 续 执 行 下 一 个 方法 ， 模 拟人 工 
的 选择 操作 。 场 景 类 如 代码 清单 5-10 所 示 。 


代码 清单 5-10 场景 类 


public class Client { 
public static void main(String[] args) { 
InstallSoftware invoker = new InstallSoftware(); 
invoker.installWizard(new Wizard()); 


以 上 程序 很 简单 ， 运 行 结果 和 随机 数 有 关 ， 每 次 的 执行 结果 都 不 相 
同 ， 需 要 读者 自己 运行 并 查看 结果 。 程 序 虽然 简单 ， 但 是 隐藏 的 问题 可 
不 简 蛙 ， 思 考 一 下 程序 有 什么 问题 。Wizard 类 把 太 多 的 方法 暴露 给 
InstallSoftware 类 ， 两 者 的 朋友 关系 太 杂 密 了 ， 耦 合 关系 变 得 异常 牢固 。 
如 果 要 将 Wizard 类 中 的 first 方 法 返回 值 的 类 型 由 int 改 为 poolean， 就 需要 
修改 InstallSoftware 类 ， 从 而 把 修改 变更 的 风险 扩散 开 了 。 因 此 ， 这 样 的 
耦合 是 极度 不 合适 的 ， 我 们 需要 对 设计 进行 重 构 ， 重 构 后 的 类 图 如 图 5- 
4 所 示 。 








InstallSoftware 


+void installWizard(Wizard wizard) -mt first() 


-int second() 
-int third() 
+vold InstallWizard() 








图 5-4 重 构 后 的 软件 安装 过 程 类 图 


在 Wizard 类 中 增加 一 个 installWizard 方 法 ， 对 安装 过 程 进行 封装 ， 
同时 把 原 有 的 三 个 public 方 法 修改 为 private 方 法 ， 如 代码 清单 5-11 所 示 。 








代码 清单 5-11 修改 后 的 导 问 类 实现 过 程 


public class 
private 
// 第 一 步 
private 


} 
// 第 二 步 
private 


} 
// 第 三 个 方法 


private 


Wizard { 
Random rand = new Random(System.currentTimeMillis()) 


int first(){ 
System.out.println(" 执 行 第 一 个 方法 ..."); 
return rand.nextInt(100); 





int second(){ 
System.out .println(" 执 行 第 二 个 方法 ,.."); 
return rand.nextInt(100); 








int third()t{ 
System.out.printlin(" 执 行 第 三 个 方法 ,..")} 
return rand.nextInt(100); 





} 
// 软 件 安装 过 程 
public void installwizard()t{ 


int first = this,.first(); 和 
// 根 据 first 返 回 的 结果 ， 看 是 否 需 要 执行 Second 











If(first>50){ 

int second = this.second(); 

If(second>50 ){ 
int third = this.third(); 
if(third >50){ 

this.first(); 

} 

} 

} 


将 三 个 步骤 的 访问 权限 修改 为 private， 同 时 把 mstallSoftware 中 的 方 
法 installWizad 移 动 到 Wizard 方 法 中 。 通 过 这 样 的 重 构 后 ，Wizard 类 就 只 
对 外 公布 了 一 个 public 方 法 ， 即 使 要 修改 first 方 法 的 返回 值 ， 有 影响 的 也 仪 


仅 只 是 Wizard 本 身 ， 其 他 关 不 受 影响 ， 这 显示 了 关 的 高 内 聚 特性 。 


对 InstallSoftware 类 进行 少量 的 修改 ， 如 代码 清单 5-12 所 示 。 


代码 清单 5-12 修改 后 的 InstallSoftware 类 


public class InstallSoftware { 
public void installWizard(Wizard wizard)t{ 
// 直 接 调 用 
wizard.installwizard( ); 


场景 类 Client 没 有 任何 改变 ， 如 代码 清单 5-10 所 示 。 通 过 进行 重 
构 ， 类 间 的 耦合 关系 变 弱 了 ， 结 构 也 清晰 了 ， 变 更 引起 的 风险 也 变 小 
名 


一 个 类 公开 的 public 属 性 或 方法 越 多 ， 修 改 时 涉及 的 面 也 就 越 大 ， 
变更 引起 的 风险 扩散 也 就 越 大 。 因 此 ， 为 了 保持 朋友 类 间 的 距离 ， 在 设 
计时 需要 反复 衡量 : 是 否 还 可 以 再 减少 public 方 法 和 属性 ， 是 否 可 以 修 
改 为 private、package-private〈 包 类 型 ， 在 类 、 方 法 、 变 量 前 不 加 访问 权 
限 ， 则 默认 为 包 类 型 ) 、Pprotected 等 访问 权限 ， 是 否 可 以 加 上 final 关 键 


户 入 
字 等 。 

















注意 “” 迪 米 特 法 则 要 求 类 “ 郑 汲 一点， 尽量 不 要 对 外 公布 太 多 的 
public 方 法 和 非 静 态 的 public 变 量 ， 尺 量 内 人 级， 多 使 用 private、package- 
private、protected 等 访问 权限 。 








3. 是 自己 的 就 是 目 己 的 


在 实际 应 用 中 经 贡 会 出 现 这 样 一 个 方法 : 放 在 本 类 中 也 可 以 ， 放 在 
其 他 类 中 也 没有 错 ， 那 怎么 去 衡量 呢 ? 你 可 以 坚持 这 样 一 个 原则 : 如果 
一 个 方法 放 在 本 类 中 ， 既 不 增加 类 间 关 系 ， 也 对 本 类 不 产生 负面 影 啊 ， 
那 就 放置 在 本 类 中 。 





4. 谨慎 使 用 Serializable 


在 实际 应 用 中 ， 这 个 问题 是 很 少 出 现 的 ， 即 使 出 现 也 会 立即 被 发 现 
并 得 到 解决 。 是 怎么 回 事 呢 ? 举 个 例子 来 说 ， 在 一 个 项 目 中 使 用 
RMI (Remote Method Invocation， 远 程 方法 调用 ) 方式 传递 一 个 
VO (Value Object， 值 对 象 ) ， 这 个 对 象 就 必须 实现 Serializable 接 口 
《仅仅 是 一 个 标志 性 接口 ， 不 需要 实现 具体 的 方法 ) ， 也 就 是 把 需要 网 
络 传输 的 对 象 进行 序列 化 ， 否 则 就 会 出 现 NotSerializableException 异 
常 。 突 然 有 一 天 ， 客 户 端 的 VO 修改 了 一 个 属性 的 访问 权限 ， 从 private 
变更 为 public， 访 问 权 限 扩 大 了 ， 如 果 服 务 器 上 没有 做 出 相应 的 变更 ， 
就 会 报 序列 化 失败 ， 就 这 么 简单 。 但 是 这 个 问题 的 产生 应 该 属于 项 目 管 
理 范畴 ， 一 个 类 或 接口 在 客户 端 已 经 变更 了 ， 而 服务 器 端 却 没 有 同步 更 
新 ， 难 道 不 是 项 目 管理 的 失职 吗 ? 














5.3 最 佳 实践 





迪 米 特 法 则 的 核心 观念 就 是 类 间 解 帮 ， 弱 耦合 ， 只 有 弱 耦 合 了 以 
后 ， 类 的 复 用 率 才 可 以 提高 。 其 要 求 的 结果 就 是 产生 了 大 量 的 中 转 或 跳 
转 类 ， 导 致 系统 的 复杂 性 提高 ， 同 时 也 为 维护 带 来 了 难度 。 读 者 在 采用 
迪 米 特 法 则 时 需要 反复 权衡 ， 既 做 到 让 结构 清晰 ， 又 做 到 高 内 聚 低 耦 


人 
口 o 














不 知道 大 家 有 没有 听 过 这 样 一 个 理论 :“ 任 何 两 个 素 不 相识 的 人 中 
间 最 多 只 隅 着 6 个 人 ， 即 只 通过 6 个 人 就 可 以 将 他 们 联系 在 一 起 ”， 这 就 
是 着 名 的 “六 度 分 阳 理 论 ”*。 如 果 将 这 个 理论 应 用 到 我 们 的 项 目 中 ， 也 就 
征 说 ， 我 和 我 要 调用 的 类 之 间 最 多 有 6 次 传递 。 呵 呵 ， 这 只 能 让 大 家 当 
个 乐子 来 看 ， 在 实际 应 用 中 ， 如 果 一 个 类 跳 转 两 次 以 上 才能 访问 到 为 一 
个 类 ， 就 需要 想 办 法 进行 章 构 了 ， 为 什么 是 两 次 以 上 呢 ?” 因 为 一 个 系统 
的 成 功 不 仅 仪 是 一 个 标准 或 是 原则 就 能 够 决定 的 ， 有 非常 多 的 外 在 因 系 
决定 ， 跳 转 次 数 越 多 ， 系 统 越 复杂 ， 维 护 就 越 困 难 ， 所 以 只 要 跳 转 不 超 


过 两 次 都 是 可 以 忍受 的 ， 这 需要 具体 问题 具体 分 析 。 





迪 米 特 法 则 要 求 类 间 解 厢 ， 但 解 看 是 有 限度 的 ， 除 非 是 计算 机 的 最 
小 单元 一 一 二 进 制 的 0O 和 1。 那 才 是 完全 解 厢 ， 在 实际 的 项 目 中 ， 需 要 适 
度 地 考虑 这 个 原则 ， 别 为 了 套用 原则 而 做 项 目 。 原 则 只 是 供 参 考 ， 如 末 








违背 了 这 个 原则 ， 项 目 也 未 必 会 失败 ， 这 就 需要 大 家 在 采用 原则 时 反复 
度量 ， 不 遵循 是 不 对 的 ， 严 格 执行 束 是 “过 狐 不 及 ”。 


第 6 章 ” 开 闭 原则 


6.1 开 闭 原则 的 定义 


在 哲学 上 ， 了 矛盾 法 则 即 对 立 统 一 的 法 则 ， 是 唯物 辩证 法 的 最 根本 法 
则 。 本 章 要 讲 的 开 半 原则 是 不 是 也 有 同样 的 重要 性 且 具 有 普 过 性 呢 ? 确 
实 ， 开 闭 原则 是 Java 世 界 里 最 基础 的 设计 原则 ， 它 指导 我 们 如 何 建立 一 
个 稳定 的 、 灵 活 的 系统 ， 先 来 看 开 闭 原则 的 定义 : 








Software entities like classes, modules and functions should be open for 
extension but closed for modifications.〈 一 个 软件 实体 如 类 、 模 块 和 函数 
应 该 对 扩展 开放 ， 对 修改 关闭 。) 


初 看 到 这 个 定义 ， 可 能 会 很 迷惑 ， 对 扩展 开放 ? 开放 什么 ? 对 修改 
关闭 ， 怎 么 关闭 ? 没关系 ， 我 会 一 步 一 步 带领 大 家 解 开 这 








我 们 做 一 件 事 情 ， 或 者 选择 一 个 方向 ， 一 般 需 要 经 历 三 个 步 又 : 

0 怎么 做 “人 简称 3W 原 则 ， 
How 取 最 后 一 。 对 于 开 闭 原则 ， 我 们 也 采用 这 三 步 来 分 析 ， 即 什 
么 是 开 闭 原则 ， 为 什么 要 使 用 开 闭 原则 ， 怎 么 使 用 开 闭 原则 。 


What 








6.2 开 闭 原则 的 庐山 真面目 


开 闭 原则 的 定义 已 经 非常 明确 地 告诉 我 们 : 软件 实体 应 该 对 扩展 开 
放 ， 对 修改 关闭 ， 其 含义 是 说 一 个 软件 实体 应 该 通过 扩展 来 实现 变化 ， 
而 不 是 通过 修改 已 有 的 代码 来 实现 变化 。 那 什么 又 是 软件 实体 呢 ? 软件 
实体 包括 以 下 几 个 部 分 





e 项 目 或 软件 产品 中 按照 一 定 的 逻辑 规则 划分 的 模块 。 


e 抽象 和 类 。 


e 方法 。 


一 个 软件 产品 只 要 在 生命 期 内 ， 都 会 发 生变 化 ， 既 然 变化 是 一 个 既 
定 的 事实 ， 我 们 就 应 该 在 设计 时 尽量 适应 这 些 变化 ， 以 提高 项 目的 稳定 
性 和 灵活 性 ， 真 正 实现 “拥抱 变化 ”。 开 闭 原则 告诉 我 们 应 尽量 通过 扩展 
软件 实体 的 行为 来 实现 变化 ， 而 不 是 通过 修改 已 有 的 代码 来 完成 变化 ， 
它 是 为 软件 实体 的 未 来 事件 而 制定 的 对 现行 开发 设计 进行 约束 的 一 个 原 
则 。 我 们 举例 说 明 什 么 是 开 闭 原则 ， 以 书店 销售 书籍 为 例 ， 其 类 图 如 图 
6-1 所 示 。 


















<<mterface>> 
IBook 









BookStore 


HString getName() 
+mt getPrice() 
+String getAuthor() 


NovelBook 
| 


+NovelBook(Strmng name, mt price, Strng author) 


图 6-1 书店 售 书 类 图 


IBook 定 义 了 数据 的 三 个 属性 : 名 称 、 价 格 和 作者 。 小 说 类 
NovelBook 是 一 个 具体 的 实现 类 ， 是 所 有 小 说 书籍 的 总 称 ，BookStore 指 
的 是 书店 ，IBook 接 口 如 代码 清单 6-1 所 示 。 





代码 清单 6-1 书籍 接口 


public interface IBook { 
// 书 籍 有 名 称 
public String getName( ); 
// 书 籍 有 售 价 
public int getPrice(); 
// 书 籍 有 作者 
public String getAuthor(); 





目前 书店 只 出 售 小 说 类 书籍 ， 小 说 类 如 代码 清单 6-2 所 示 。 


代码 清单 6-2 小 说 类 


public class NovelBook implements IBook { 
// 书 籍 名 称 
private String name 
// 书 籍 的 价格 
private int price; 
// 书 籍 的 作者 
private String author; 
// 通 过 构造 函数 传递 书籍 数据 


public NovelBook(String _name,int _price,String _author)t{ 


this.name = _name， 
this.price = _price; 
this.author = _author ， 
} 
// 获 得 作者 是 谁 


public String getAuthor() { 
return this.author; 


} 

// 书 籍 叫 什么 名 字 

public String getName() { 
return this.name; 


} 

// 获 得 书籍 的 价格 

public int getPrice() { 
return this.price; 

} 





注意 ”我们 把 价格 定义 为 int 类 型 并 不 是 错误 ， 在 非 金融 类 项 目 中 
对 货币 处 理 时 ， 一 般 取 2 位 精度 ， 通 第 的 设计 方法 是 在 运算 过 程 中 扩大 
100 倍 ， 在 需要 展示 时 再 缩小 100 倍 ， 减 少 精度 带 来 的 误差 。 














书店 售 书 的 过 程 如 代码 清单 6-3 所 示 。 


代码 清单 6-3 书店 售 书 类 


public class BookStore { 

private final static ArrayList<IBook> bookList = new ArrayLi 

/Vstatic 静 态 模块 初始 化 数据 ， 实 际 项 目 中 一 般 是 由 持久 层 完 成 

statict{ 
bookList.add(new NovelBook(" 天 龙 八 部 ", 3200, "金庸 "))，; 
bookList.add(new NovelBook(" 巴 黎 圣 母 院 ", 5600, " 雨 果 ")); 
bookList.add(new NovelBook(" 悲 惨 世 界 ", 3500," 雨 果 ")); 
bookList.add(new NovelBook(" 金 瓶 梅 ", 4300," 兰 陵 笑 笑 生 ")) 


} 

// 模 拟 书店 买书 

public static void main(String[] args) { 
NumberFormat formatter = NumberFormat .getCurrencyIns 
formatter.setMaximumFractionDigits(2); 
System.out.println("----------- 书店 卖 出 去 的 书籍 记录 如 下 : 
for(IBook book:bookList){ 

System.out .println( "书籍 名 称 : " + book.getName 
book .getAuthor()+"\t 书 籍 价格 : "+ formatter.format (book.get 
100.0)+" 元 "); 

} 
































在 BookStore 中 声明 了 一 个 静态 模块 ， 实 现 了 数据 的 初始 化 ， 这 部 
分 应 该 是 从 持久 层 产 生 的 ， 由 持久 层 框 架 进 行 管理 ， 运 行 结 末 如 下 : 








~ 书店 卖 出 去 的 书籍 记录 如 下 : -------------- 

书籍 名 称 : 天龙 八 部 ”书籍 作者 : 金良 书籍 价格 : 茸 25.60 元 
书籍 名 称 : 巴黎 圣母 院 ”书籍 作者 : 雨 果 书籍 价格 : 茸 50.40 元 
书籍 名 称 ; 悲惨 世界 ”书籍 作者 : 雨 果 书籍 价格 : 茸 28.00 元 
书籍 名 称 : 金瓶 梅 书籍 作者 : 兰 陵 笑 笑 生 ”书籍 价格 : 兰 38.70 元 











项 目 投产 了 ， 书 籍 正常 销售 出 去 ， 书 店 也 局 利 了 。 从 2008 年 开始 ， 
全 球 经 济 开 始 下 滑 ， 对 零售 业 影 啊 比 较 大 ， 书 店 为 了 生存 开始 打折 销 
售 : 所 有 40 元 以 上 的 书籍 9 折 销 售 ， 其 他 的 8 折 销 售 。 对 已 经 投产 的 项 目 
来 次， 这 就 是 一 个 变化 ， 我 们 应 该 如 何 应 对 这 样 一 个 需求 变化 ? 有 如 下 


三 种 方法 可 以 解决 这 个 问题 : 
e 修改 接口 


在 IBook 上 新 增加 一 个 方法 getOffPrice0， 专 门 用 于 进行 打折 处 理 ， 
所 有 的 实现 类 实现 该 方法 。 但 是 这 样 修改 的 后 果 就 是 ， 实 现 类 
NovelBook 要 修改 ，BookStore 中 的 main 方 法 也 修改 ， 同 时 IBook 作 为 接 
口 应 该 是 稳定 且 可 靠 的 ， 不 应 该 经 常 发 生变 化 ， 和 否则 接口 作为 契约 的 作 
用 就 失去 了 效能 。 因 此 ， 该 方案 否定 。 




















。 修改 实现 类 


修改 NovelBook 类 中 的 方法 ， 直 接 在 getPrice() 中 实现 打折 人 处理， 好 
办 法 ， 我 相信 大 家 在 项 目 中 经 常 使 用 的 就 是 这 样 的 办 法 ， 通 过 class 文 件 
蔡 换 的 方式 可 以 完成 部 分 业务 变化 《或 是 缺陷 修复 ) 。 该 方法 在 项 目 有 
明确 的 章程 《团队 内 约束 ) 或 优良 的 架构 设计 时 ， 是 一 个 非常 优秀 的 方 
法 ， 但 是 该 方法 还 是 有 缺陷 的 。 例 如 采购 书籍 人 员 也 是 要 看 价格 的 ， 由 
于 该 方法 已 经 实现 了 打折 处 理 价 格 ， 因 此 采购 人 员 看 到 的 也 是 打折 后 的 
价格 ， 会 因 信 息 不 对 称 而 出 现 决策 失误 的 情况 。 因 此 ， 该 方案 也 不 是 一 
个 最 优 的 方案 。 








通过 扩展 实现 变化 


增加 一 个 子 类 OffNovelBook， 窗 写 getPrice 方 法 ， 高 层次 的 模块 


(也 就 是 static 静 态 模 块 区 ) 通过 OffNovelBook 类 产生 新 的 对 象 ， 完 成 业 
务 变 化 对 系统 的 最 小 化 开发 。 好 办 法 ， 修 改 也 少 ， 风 险 也 小 ， 修 改 后 的 
类 图 如 图 6-2 所 示 。 








BookStore 


+String getName() 
+int getPrice() 
+String getAuthor() 


NovelBook 
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+NovelBook(String name, mt price, Strmg author) 


OffNovelBook 


+nt getPrice() 





复写 getPrice 方 法 





图 6-2 扩展 后 的 书店 售 书 类 图 


OffNovelBook 类 继承 了 NovelBook， 并 有 履 写 了 getPrice 方 法 ， 不 修改 


原 有 的 代码 。 新 增加 的 子 类 OffNovelBook 如 代码 清单 6-4 所 示 。 


代码 清单 6-4 打折 销售 的 小 说 类 


public class OffNovelBook extends NovelBook { 
public OffNovelBook(String _name,int _price,String _author)t{ 
super(_name,_price,_author); 


} 
// 履 写 销售 价格 
@Override 
public int getPrice(){ 
// 原 价 
int selfprice = super.getPrice(); 
int offPrice=0; 
if(selLfPrice>4000){f // 原 价 大 于 40 元 ， 则 打 9 折 
offPrice = selfPrice * 90 /100; 











}elsef{ 
offPrice = selfPrice * 80 /100; 


return offPrice,; 


很 简单 ， 仅 仅 覆 写 了 getPrice 方 法 ， 通 过 扩展 完成 了 新 增加 的 业 
务 。 书 店 类 BookStore 需 要 依赖 子 类 ， 人 代码 稍 作 修改 ， 如 代码 清单 6-5 所 


钞 。 


代码 清单 6-5 书店 打折 销售 类 


public class BookStore { 

private final static ArrayList<IBook> bookList = new ArrayLi 

//static 静 态 模 块 初始 化 数据 ， 实 际 项 目 中 一 般 是 由 持久 层 完成 

statict{ 
bookList.add(new 0ffNovelBook(" 天 龙 八 部 ", 3200, "金庸 ")) 
bookList.add(new 0ffNovelBook(" 巴 黎 圣 母 院 ", 5600," 雨 果 " 
bookList.add(new 0ffNovelBook(" 悲 惨 世 界 ", 3500," 雨 果 ")) 
bookList.add(new 0ffNovelBook(" 人 金瓶梅 ", 4300," 兰 陵 笑 笑 生 


} 
// 模 拟 书店 买书 


public static void main(String[] args) { 



































NumberFormat formatter = NumberFormat .getCurrencyIns 
formatter.setMaximumFractionDigits(2); 
System.out.println("----------- 书店 卖 出 去 的 书籍 记录 如 下 : 
for(IBook book:bookList)t{ 
System.out.printLn(" 书 籍 名 称 : " + book.getNar 





} 
} 
} 

运行 结果 如 下 所 示 。 

Se 书 唐 卖 出 类 的 书籍 记录 如 下 s 二- 
书籍 名 称 : 天 龙 八 部 ”书籍 作者 : 金良 书籍 价格 : 竺 25.60 元 
书籍 名 称 : 巴黎 圣母 院 ”书籍 作者 : 两 果 书籍 价格 : 笠 50.40 元 
书籍 名 称 : 悲惨 世界 ”书籍 作者 : 雨 果 书籍 价格 : 入 28.00 元 
书籍 名 称 : 金瓶 梅 书籍 作者 : 兰 陵 笑 笑 生 ”书籍 价格 : 芋 38.70 元 








OK， 打 折 销 售 开发 完成 了 。 看 到 这 里 ， 各 位 可 能 有 想法 了 : 增加 
了 一 个 OffNoveBook 类 后 ， 你 的 业务 逻辑 还 是 修改 了 ， 你 修改 了 static 毅 
态 模块 区 域 。 这 部 分 确实 修改 了 ， 该 部 分 属于 高 层次 的 模块 ， 是 由 持久 
层 产 生 的 ， 在 业务 规则 改变 的 情况 下 高 层 模块 必须 有 部 分 改变 以 适应 新 
业务 ， 改 变 要 尽量 地 少 ， 防 止 变化 风险 的 扩散 。 











注意 开 财 原则 对 扩展 开放 ， 对 修改 关闭 ， 并 不 意味 着 不 做 任何 
修改 ， 低 层 模 块 的 变更 ， 必 然 要 有 高 层 模 块 进行 厢 合 ， 合 则 束 是 一 个 孤 
立 无 意义 的 代码 片段 。 





我 们 可 以 把 变化 归纳 为 以 下 三 种 类 型 : 


。 逻辑 变化 


只 变化 一 个 逻辑 ， 而 不 涉及 其 他 模块 ， 比 如 原 有 的 一 个 算法 是 
a*b+c， 现 在 需要 修改 为 a*b*c， 可 以 通过 修改 原 有 类 中 的 方法 的 方式 来 
完成 ， 前 提 条 件 是 所 有 依赖 或 关联 类 都 按照 相同 的 逻辑 处 理 。 








e 子 模块 变化 


一 个 模块 变化 ， 会 对 其 他 的 模块 产生 影响 ， 特 别 是 一 个 低层 次 的 模 
块 变化 必然 引起 高 层 模块 的 变化 ， 因 此 在 通过 扩展 完成 变化 时 ， 高 层次 
的 模块 修改 是 必然 的 ， 刚 刚 的 书籍 打折 处 理 就 是 类 似 的 处 理 模 块 ， 该 部 
分 的 变化 甚至 会 引起 界面 的 变化 。 





e 9 可见 视 图 变化 


可 见 视图 是 提供 给 客户 使 用 的 界面 ， 如 JSP 程 序 、Swing 界 面 等 ， 该 
部 分 的 变化 一 般 会 引起 连锁 反应 特别 是 在 国内 做 项 目 ， 做 欧美 的 外 包 
项 目 一 般 不 会 影响 太 大 〉 。 如 果 仪 仅 是 界面 上 按钮 、 文 字 的 重新 排 布 倒 
古 简单 ， 最 司空 见 惯 的 是 业务 厢 合 变化 ， 什 么 意思 呢 ? 一 个 展示 数据 的 
列表 ， 按 照 原 有 的 需求 是 6 列 ， 突 然 有 一 天 要 增加 1 列 ， 而 且 这 一 列 要 路 
N 张 表 ， 处 理 M 个 逻辑 才能 展现 出 来 ， 这 样 的 变化 是 比较 恐怖 的 ， 但 还 
古 可 以 通过 扩展 来 完成 变化 ， 这 束 要 看 我 们 原 有 的 设计 是 否 灵 活 。 

















我 们 再 来 回顾 一 下 书店 销售 书籍 的 程序 ， 首 先是 我 们 有 一 个 还 算 灵 
活 的 设计 《不 灵活 是 什么 样子 ? BookStore 中 所 有 使 用 到 IBook 的 地 方 全 
部 修改 为 实现 类 ， 然 后 再 扩展 一 个 ComputerBook 书 籍 ， 你 就 知道 什么 是 
不 灵活 了) ; 然后 有 一 个 需求 变化 ， 我 们 通过 扩展 一 个 子 类 拥抱 了 变 
化 ; 最 后 把 子 类 投入 运行 环境 中 ， 新 逻辑 正式 投产 。 通 过 分 析 ， 我 们 友 
现 并 没有 修改 原 有 的 模块 代码 ，IBook 接 口 没 有 改变 ，NovelBook 类 没有 
改变 ， 这 属于 已 有 的 业务 代码 ， 我 们 保持 了 历史 的 纯洁 性 。 放 弃 修 改 历 
史 的 想法 吧 ， 一 个 项 目的 基本 路 径 应 该 是 这 样 的 : 项 目 开 发 、 重 构 、 测 
试 、 投 产 、 运 维 ， 其 中 的 重 构 可 以 对 原 有 的 设计 和 代码 进行 修改 ， 运 维 
尽量 减少 对 原 有 代码 的 修改 ， 保 持 历史 代码 的 纯洁 性 ， 提 高 系统 的 稳定 
人 


























6.3 为 什么 要 采用 开 闭 原则 


每 个 事物 的 诞生 部 有 它 存 在 的 必要 性 ， 存 在 即 合理 ， 那 开 闭 原则 的 
存在 也 是 合理 的 ， 为 什么 这 么 说 呢 ? 





首先 ， 开 闭 原则 非常 著名 ， 只 要 是 做 面 同 对 象 编程 的 ， 甫 管 是 什么 
语言 ，Java 也 好 ，C++ 也 好 ， 或 者 是 Smalltalk， 在 开发 时 都 会 提 及 开 闭 
原则 。 


其 次 ， 开 闭 原则 是 最 基础 的 一 个 原则 ， 前 五 革 市 介绍 的 原则 都 是 开 
财 原则 的 具体 形态 ， 也 惑 是 说 前 五 个 原则 就 是 指导 设计 的 工具 和 方法 ， 
而 开 闭 原则 才 是 其 精神 领袖 。 换 一 个 角度 来 理解 ， 依 照 Java 语 言 的 称 
请 ， 开 闭 原则 是 抽象 类 ， 其 他 五 大 原则 是 具体 的 实现 类 ， 开 闭 原则 在 面 
问 对 象 设计 领域 中 的 地 位 就 类 似 于 牛顿 第 一 定律 在 力学 、 义 股 定律 在 几 
何 学 、 质 能 方程 在 狭义 相对 论 中 的 地 位 ， 其 地 位 无 人 能 及 。 




















最 后 ， 开 闭 原则 是 非常 重要 的 ， 可 通过 以 下 几 个 方面 来 理解 其 重要 


1. 开 闭 原则 对 测试 的 影响 


所 有 已 经 投产 的 代码 部 是 有 意义 的 ， 并 且 都 受 系统 规则 的 约束 ， 这 
样 的 代码 都 要 经 过 “ 千 锤 百 炼 * 的 测试 过 程 ， 不 仅 保 证 逻辑 是 正确 的 ， 还 











要 保证 苛刻 条 件 《〈 高 压力 、 有 异常、 错误 ) 下 不 产生 “有 毒 代 

码 ”(Poisonous Code) ， 因 此 有 变化 提出 时 ， 我 们 就 需要 考虑 一 下 ， 原 
有 的 健壮 代码 是 否 可 以 不 修改 ， 仅 仅 通过 扩展 实现 变化 呢 ? 人 否则， 就 需 
要 把 原 有 的 测试 过 程 回 笼 一 过 ， 需 要 进行 单元 测试 、 功 能 测试 、 集 成 测 
试 甚至 是 验收 测试 ， 现 在 虽然 在 大 力 提倡 自动 化 测试 工具 ， 但 是 仍然 代 
蔡 不 了 人 工 的 测试 工作 。 














以 上 面 提 到 的 书店 售 书 为 例 ，IBook 接 口 写 完了 ， 实 现 类 NovelBook 
也 写 好 了 ， 我 们 需要 写 一 个 测试 类 进行 测试 ， 测 试 类 如 代码 清单 6-6 所 


帮 \。 


代码 清单 6-6 小 说 类 的 单元 测试 


public class NovelBookTest extends TestCase { 
private String name = "平凡 的 世界 "， 
private int price = 6000; 


private String author = "路 遥 " ; 
private IBook novelBook = new NovelBook(name,price,author); 
// 测 试 getPrice 方 法 





public void testGetPrice( ) 
// 原 价 销售 ， 根 据 输 入 和 输出 的 值 是 否 相等 进行 断言 
super.assertEquals(this.price, this.novelBook.getPri 














单元 测试 通过 ， 显 示 绿 条 。 在 单元 测试 中 ， 有 一 名 非常 有 名 的 话 ， 
叫做 "Keep the bar green to keep the code clean"， 即 保持 绿 条 有 利于 代码 
整洁 ， 这 是 什么 意思 呢 ? 绿 条 就 是 Junit 运 行 的 两 种 结果 中 的 一 种 : 要 么 


古 红 条 ， 单 元 测试 失败 ;， 要 么 是 绿 条 ， 单 元 测试 通过 。 一 个 方法 的 测试 








方法 一 般 不 少 于 3 种 ， 为 什么 呢 ? 首先 是 正 稼 的 业务 逻辑 要 保证 测试 
到 ， 其 次 是 边界 条 件 要 测试 到 ， 然 后 是 腊 常 要 测试 到 ， 比 较 重要 的 方法 
的 测试 方法 甚至 有 十 多 种 ， 而 且 单 元 测试 是 对 类 的 测试 ， 类 中 的 方法 籽 
合 是 允许 的 ， 在 这 样 的 条 件 下 ， 如 果 再 想 厦 通过 修改 一 个 方法 或 多 个 方 
法 代码 来 完成 变化 ， 基 本 上 就 是 病人 说 梦 ， 该 类 的 所 有 测试 方法 都 要 重 
构 ， 想 象 一 下 你 在 一 堆 你 并 不 熟悉 的 代码 中 进行 重 构 时 的 感觉 吧 ! 





在 书店 售 书 的 例子 中 ， 增 加 了 一 个 打折 销售 的 需求 ， 如 果 我 们 直接 
修改 getPrice 方 法 来 实现 业务 需求 的 变化 ， 那 就 要 修改 单元 测试 类 。 想 
想 看 ， 我 们 举 的 这 个 例子 是 非常 简单 的 ， 如 果 古 一 个 复杂 的 逻辑 ， 你 的 
测试 类 就 要 修改 得 面目 全 非 。 还 有 ， 在 实际 的 项 目 中 ， 一 个 类 一 般 只 有 
一 个 测试 类 ， 其 中 可 以 有 很 多 的 测试 方法 ， 在 一 扒 本 来 就 很 复杂 的 断言 
中 进行 大 量 修改 ， 难 免 会 出 现 测 试 遗漏 情况 ， 这 是 项 目 经 理 很 难 容 妨 的 
事情 。 








所 以 ， 我 们 需要 通过 扩展 来 实现 业务 负 辑 的 变化 ， 而 不 是 修改 。 上 
面 的 例子 中 通过 增加 一 个 子 类 OffNovelBook 来 完成 了 业务 需求 的 变化 ， 
这 对 测试 有 什么 好 处 呢 ? 我 们 重新 生成 一 个 测试 文件 
OfftNovelBookTest， 然 后 对 getPrice 进 行 测试 ， 单 元 测试 是 孤立 测试 ， 只 
要 保证 我 提供 的 方法 正确 就 成 了 ， 其 他 的 我 不 管 ，OffNovelBookTest 如 
代码 清单 6-7 所 示 。 





代码 清单 6-7 打折 销售 的 小 说 类 单元 测试 


public class OffNovelBookTest extends TestCase { 
private IBook below40NovelBook = new 0ffNovelBook(" 平 凡 的 世界 " 
private IBook above40NovelBook = new 0ffNovelBook(" 平 凡 的 世界 " 
// 测 试 低 于 40 元 的 数据 是 否 是 打 8 折 
public void testGetPpriceBelow40() { 
super.assertEquals(2400, this.below40NovelBook.getPr 





} 
// 测 试 大 于 46 的 书籍 是 否 是 打 9 折 
public void testGetPriceAbove40( ){ 
super.assertEquals(5400, this.above40NovelBook.getPr 
} 


新 增加 的 类 ， 新 增加 的 测试 方法 ， 只 要 保证 新 增加 类 是 正确 的 就 可 
以 了 。 


2. 开 闭 原则 可 以 提高 复 用 性 


在 面 癌 对 象 的 设计 中 ， 所 有 的 逻辑 都 是 从 原子 馆 辑 组 合 而 来 的 ， 而 
不 是 在 一 个 类 中 独立 实现 一 个 业务 逻辑 。 只 有 这 样 代 码 才 可 以 复 用 ， 粒 
度 越 小 ， 被 复 用 的 可 能 性 就 越 大 。 那 为 什么 要 复 用 呢 ? 减少 代码 量 ， 避 
免 相 同 的 逻辑 分 散在 多 个 角落 ， 避 免 日 后 的 维护 人 员 为 了 修改 一 个 微小 
的 缺陷 或 增加 新 功能 而 要 在 整个 项 目 中 到 处 碍 找 相 关 的 代码 ， 然 后 发 出 
对 开 有 人员 “极度 失望 ?的 感慨 。 那 怎么 才能 提高 复 用 率 呢 ? 缩小 逻辑 粒 
度 ， 和 直到 一 个 逻辑 不 可 再 拆 分 为 止 。 


3. 开 财 原则 可 以 提高 可 维护 性 


一 天 软件 投产 后 ， 维 护 人 员 的 工作 不 仅仅 是 对 数据 进行 维护 ， 还 可 
能 要 对 程序 进行 扩展 ， 维 护 人 员 最 乐意 做 的 事情 束 是 扩展 一 个 类 ， 而 不 








是 修改 一 个 类 ， 甫 管 原 有 的 代码 写 得 多 么 优秀 还 是 多 么 糟 灯 ， 让 维护 人 
员 读 懂 原 有 的 代码 ， 然 后 再 修改 ， 是 一 件 很 痛 百 的 事情 ， 不 要 让 他 在 原 
有 的 代码 海洋 里 游 尺 完毕 后 再 修改 ， 那 是 对 维护 人 员 的 一 种 折磨 和 扒 
残 。 





4. 面 癌 对 象 开 发 的 要 求 


万 物 篆 对 象 ， 我 们 需要 把 所 有 的 事物 都 抽象 成 对 象 ， 然 后 针对 对 象 

行 操作 ， 但 是 万 物 彰 运动 ， 有 运动 就 有 变化 ， 有 变化 束 要 有 策略 去 应 
对 ， 怎 么 快速 应 对 呢 ? 这 就 需要 在 设计 之 初 考虑 到 所 有 可 能 变化 的 因 
素 ， 然 后 留 下 接口 ， 等 待 <" 可 能 ”转变 为 “现实 ” 














6.4 如 何 使 用 开 财 原则 





开 闭 原则 是 一 个 非常 虚 的 原则 ， 前 面 5 个 原则 是 对 开 闭 原则 的 具体 
解释 ， 但 是 开 闭 原则 并 不 局 限于 这 么 多 ， 它 “ 虚 ” 得 没有 边界 ， 就 像 “ 好 
好 学 习 ， 天 天 同上 ?的 口号 一 样 ， 告 诉 我 们 要 好 好 学 习 ， 但 是 学 什么 ， 
怎么 学 并 没有 告诉 我 们 ， 需 要 去 体会 和 掌握， 开 闭 原则 也 是 一 个 口号 ， 
那 我 们 怎么 把 这 个 口号 应 用 到 实际 工作 中 呢 ? 














1. 抽象 约束 


抽象 是 对 一 组 事物 的 通用 描述 ， 没 有 有 具体 的 实现 ， 也 惑 表示 它 可 以 
有 非常 多 的 可 能 性 ， 可 以 跟随 需求 的 变化 而 变化 。 因 此 ， 通 过 接口 或 抽 
象 类 可 以 约束 一 组 可 能 变化 的 行为 ， 并 且 能 够 实现 对 扩展 开放 ， 其 包含 
三 层 含义 : 第 一 ， 通 过 接口 或 抽象 类 约束 扩展 ， 对 扩展 进行 边界 限定 ， 
不 允许 出 现在 接口 或 抽象 类 中 不 存在 的 public 方 法 ， 第 二 ， 参 数 类 型 、 
引用 对 象 尽 量 使 用 接口 或 者 抽象 类 ， 而 不 是 实现 类 ; 第 三 ， 抽 象 层 尽量 
保持 稳定 ， 一 旦 确定 即 不 允许 修改 。 还 是 以 书店 为 例 ， 目 前 只 是 销售 小 
说 类 书籍 ， 单 一 经 营 毕 竞 是 有 风险 的 ， 于 是 书店 新 增加 了 计算 机 书籍 ， 
它 不 仪 包含 书籍 名 称 、 作 者 、 价 格 等 信息 ， 还 有 一 个 独特 的 属性 ， 面 问 
的 是 什么 领域 ， 也 就 是 它 的 范围 ， 比 如 是 和 编程 语言 相关 的 ， 还 是 和 数 
据 库 相关 的 ， 等 等 ， 修 改 后 的 类 图 如 图 6-3 所 示 。 

















<<interface>> 
[Book 


+Strng getName() 
+int getPrice() 
+Strmg getAuthor() 








人 





<<mnterface>> 
IComputerBook 
Eee 
+String getScope() 





ComputerBook 
| 
FE | 


图 6-3 增加 业务 品种 后 的 书店 售 书 类 图 


增加 了 一 个 接口 [ComputerBook 和 实现 类 Computer- Book， 而 
BookStore 不 用 做 任何 修改 就 可 以 完成 书店 销售 计算 机 书籍 的 业务 。 计 
算 机 书籍 接口 如 代码 清单 6-8 所 示 。 


代码 清单 6-8 计算 机 书籍 接口 


public interface IComputerBook extends IBook{ 
// 计 算 机 书籍 是 有 一 个 范围 
public String getScope(); 








很 简单 ， 计 算 机 书籍 增加 了 一 个 方法 ， 就 是 获得 该 书籍 的 范围 ， 同 
时 继承 IBook 接 口 ， 毕 竟 计 算 机 书籍 也 是 书籍 ， 其 实现 如 代码 清单 6-9 所 


修 。 


代码 清单 6-9 计算 机 书籍 类 


public class ComputerBook implements IComputerBook { 
private String name; 
private String scope; 
private String author; 
private int price; 
public ComputerBook(String _name,int _price,String _author,s 
this.name=_name; 


this.price = _price; 
this.author = _author ， 
this.scope = _scope; 


} 
public String getScope() { 
return this.scope; 


} 
public String getAuthor() { 
return this.author; 


} 

public String getName() { 
return this.name; 

’ 


public int getPrice() { 
return this.price; 
} 


这 也 很 简单 ， 实 现 IComputerBook 就 可 以 ， 而 BookStore 类 没有 做 任 
何 的 修改 ， 只 是 在 static 静 态 模块 中 增加 一 条 数据 ， 如 代码 清单 6-10 所 


夏 。 


代码 清单 6-10 书店 销售 计算 机 书籍 


public class BookStore { 
private final static ArrayList<IBook> bookList = new ArrayLi 
//static 静 态 模 块 初始 化 数据 ， 实 际 项 目 中 一 般 是 由 持久 层 完 成 
statict{ 
































bookList.add(new NovelBook(" 天 龙 八 部 ", 3200, "金庸")); 
bookList.add(new NovelBook(" 巴 歼 圣 母 院 ", 5600, " 雨 果 ")); 
bookList,add(new NovelBook(" 悲 惨 世 界 "， 3500," 雨 果 ")); 
bookList.add(new NovelBook(" 金 瓶 梅 ", 4300," 兰 陵 笑 笑 生 ")) 
// 增 加 计算 机 书籍 

bookList.add(new ComputerBook("Think in Java",4300," 





} 
// 模 拟 书店 卖 书 


public static void main(String[] args) { 


NumberFormat formatter = NumberFormat .getCurrencyIns 
formatter.setMaximumFractionDigits(2); 
System.out.println("----------- 书店 卖 出 去 的 书籍 记录 如 下 : 
for(IBook book:bookList)t{ 

System.out.println( "书籍 名 称 : " + book.getNa 
} 





书店 开始 销售 计算 机 书籍 ， 运 行 结果 如 下 所 示 。 


书籍 名 称 : 
书籍 名 称 : 
书籍 名 称 : 
书籍 名 称 : 





有 书店 卖 出 去 的 书籍 记录 如 下 ; -一 

















: 天 龙 八 间 书籍 作者 : 金庸 书籍 价格 ， 圣 32.00 元 
巴黎 圣母 院 书籍 作者 : 雨 果 书籍 价格 ， 茸 56.00 元 
悲惨 世界 书籍 作者 : 雨 果 书籍 价格 ， 圣 35.00 元 
金瓶 梅 书籍 作者 : 兰 陵 笑 笑 生 ”书籍 价格 : 闻 43.00 元 
Think in Java 书籍 作者 : Bruce Eckel 书籍 价格 ， 茸 43.00 元 











如 果 我 是 负责 维护 的 ， 我 就 非常 乐意 做 这 样 的 事情 ， 简 单 而 且 不 需 
要 与 其 他 的 业务 进行 耦合 。 我 唯一 需要 做 的 事情 就 是 在 原 有 的 代码 上 添 
砖 加 瓦 ， 然 后 就 可 以 实现 业务 的 变化 。 我 们 来 看 看 这 段 代 码 有 哪 几 层 含 


义 : 











首先 ，ComputerBook 类 必须 实现 IBook 的 三 个 方法 ， 是 通过 
IComputerBook 接 口传 递 进来 的 约束 ， 也 就 是 我 们 制定 的 IBook 接 口 对 扩 
展 类 CompnuterBook 产 生 了 约束 力 ， 正 是 由 于 该 约束 力 ，BookStore 类 才 
不 需要 进行 大 量 的 修改 。 





其 次 ， 如 果 原 有 的 程序 设计 采用 的 不 是 接口 ， 而 是 实现 类 ， 那 会 出 
现 什 么 问题 呢 ? 我 们 把 BookStore 类 中 的 私有 变量 bookList 修 改 一 下 ， 如 
下 面 的 代码 所 示 。 


private final static ArrayList<NovelBook> bookList = new ArrayLis 


把 原 有 IBook 的 依赖 修改 为 对 NovelBook 实 现 类 的 依赖 ， 想 想 看 ， 我 
们 这 次 的 扩展 是 否 还 能 继续 下 去 呢 ? 一 旦 这 样 设计 ， 我 们 就 根本 没有 办 
法 扩展 ， 需 要 修改 原 有 的 业务 逻辑 (也 就 是 main 方 法 ) ， 这 样 的 扩展 基 
本 上 就 是 形同虚设 。 








最 后 ， 如 采 我 们 在 IBook 上 增加 一 个 方法 getScope， 是 否 可 以 呢 ? 答 
案 是 不 可 以 ， 因 为 原 有 的 实现 类 NovelBook 已 经 在 投产 运行 中 ， 它 不 需 
要 该 方法 ， 而 且 接 口 是 与 其 他 模块 交流 的 契约 ， 修 改 巢 约束 等 于 让 其 他 
模块 修改 。 因 此 ， 接 口 或 抽象 类 一 旦 定义 ， 就 应 该 立即 执行 ， 不 能 有 修 
改 接 口 的 思想 ， 除 非 是 彻底 的 大 返工 。 











所 以 ， 要 实现 对 扩展 开放 ， 首 要 的 前 提 条 件 就 是 抽象 约束 。 


2. 元 数据 Cmetadata) 控制 模块 行为 





编程 是 一 个 很 苦 很 素 的 活 ， 那 怎么 才能 减轻 我 们 的 压力 呢 ? 答案 是 
尽量 使 用 元 数据 来 控制 程序 的 行为 ， 减 少 重复 开发 。 什 么 是 元 数据 ? 用 
来 描述 环境 和 数据 的 数据 ， 通 俗 地 说 就 是 配置 参数 ， 参 数 可 以 从 文件 中 
获得 ， 也 可 以 从 数据 库 中 获得 。 举 个 非常 简单 的 例子 ，login 方 法 中 提供 
了 这 样 的 逻辑 : 先 检 查 卫 地址 是 否 在 允许 访问 的 列表 中 ， 然 后 再 决定 是 
否 需要 到 数据 库 中 验证 密码 〈 如 果 采 用 SSH 架 构 ， 则 可 以 通过 Struts 的 拦 
截 器 来 实现 ) ， 该 行为 就 是 一 个 典型 的 元 数据 控制 模块 行为 的 例子 ， 其 
中 达到 极致 的 就 是 控制 反 转 (Inversion of Control) ， 使 用 最 多 的 就 是 
Spring 容 器 ， 在 SpringContext 配 置 文件 中 ， 基 本 配置 如 代码 清单 6-11 所 


小 。 











代码 清单 6-11 SpringContext 的 基本 配置 文件 


<bean id="father" class="xxx.xxx.xxx.Father" /> 
<bean id="xx" CaSsSs="XXX,XXX,XXX,XXX"> 

<property name="biz" ref="father"></property> 
</bean> 


然后 ， 通 过 建立 一 个 Father 类 的 子 类 Son， 完 成 一 个 新 的 业务 ， 同 时 
修改 SpringContext 文 件 ， 修 改 后 的 文件 如 代码 清单 6-12 所 示 。 


代码 清单 6-12 扩展 后 的 SpringContext 配 置 文件 


<bean id="son" class="xxXx.xxx.xxx.Son" /> 
<bean id="xx" CasSs="XXX,XXX,XXX,XXX"> 

<property name="biz" ref="son"></property> 
</bean> 


通过 扩展 一 个 子 类 ， 修 改 配 置 文件 ， 完 成 了 业务 变化 ， 这 也 是 采用 


框架 的 好 处 。 


3. 制定 项 目 章程 











在 一 个 团队 中 ， 建 立项 目 章程 是 非常 重要 的 ， 因 为 章程 中 指定 了 上 所 
有 人 员 都 必须 遵守 的 约定 ， 对 项 目 来 说 ， 约 定 优 于 配置 。 相 信 大 家 都 做 
过 项 目 ， 会 发 现 一 个 项 目 会 产生 非常 多 的 配置 文件 。 举 个 简单 的 例子 ， 
以 SSH 项 目 开发 为 例 ， 一 个 项 目 中 的 Bean 配 置 文件 就 非常 多 ， 管 理 非常 
拱 烦 。 如 果 震 要 扩展 ， 就 需要 增加 子 类 ， 并 修改 SpringContext 文 件 。 然 
而 ， 如 采 你 在 项 目 中 指定 这 样 一 个 章程 : 所 有 的 Bean 都 自动 注入 ， 使 用 
Annotation 进 行 装 配 ， 进 行 扩展 时 ， 甚 至 只 用 写 一 个 子 类 ， 然 后 由 持久 
层 生 成 对 象 ， 其 他 的 部 不 需要 修改 ， 这 就 需要 项 目 内 约束 ， 每 个 项 目 成 
员 都 必须 遵守 ， 该 方法 需要 一 个 团队 有 较 高 的 目 沉 性， 需要 一 个 较 长 时 
间 的 磨合 ， 一 旦 项 目 成 员 都 熟悉 这 样 的 规则 ， 比 通过 接口 或 抽象 类 进行 
约束 效率 更 高 ， 而 且 扩展 性 一 点 也 没有 减少 。 

















4. 封装 变化 


对 变化 的 封 沪 包含 两 层 含义 :第 一 ， 将 相同 的 变化 封装 到 一 个 接口 
或 抽象 类 中 ; 第 二 ， 将 不 同 的 变化 封装 到 不 同 的 接口 或 抽象 类 中 ， 不 应 
该 有 两 个 不 同 的 变化 出 现在 同一 个 接口 或 抽象 类 中 。 封 装 变化 ， 也 就 是 
受 保护 的 变化 〈protected variations) ， 找 出 预计 有 变化 或 不 稳定 的 点 ， 
我 们 为 这 些 变化 点 创建 稳定 的 接口 ， 准 确 地 讲 是 封装 可 能 发 生 的 变化 ， 





一 旦 预测 到 或 “第 六 感 ”" 发 党 有 变化 ， 就 可 以 进行 封装，23 个 设计 模式 都 
征 从 各 个 不 同 的 角度 对 变化 进行 封装 的 ， 我 们 会 在 各 个 模式 中 逐步 讲 


慌 


6.5 最 佳 实践 





软件 设计 最 大 的 难题 就 是 应 对 需求 的 变化 ， 但 是 纷繁 复杂 的 需求 变 
化 又 是 不 可 预料 的 。 我 们 要 为 不 可 预料 的 事情 做 好 准备 ， 这 本 里 束 是 一 
件 非常 痛 百 的 事情 ， 但 是 大 师 们 还 是 给 我 们 提出 了 非常 好 的 6 大 设计 原 
则 以 及 23 个 设计 模式 来 “封闭 ?未 来 的 变化 ， 我 们 在 前 5 章 中 讲 过 如 下 设 
计 原 则 。 





e Single Responsibility Principle: 单一 职责 原则 
e Open Closed Principle: 开 闭 原则 
e Liskov Substitution Principle: 里 氏 蔡 换 原 则 


e Law of Demeter: 迪 米 特 法 则 





e@ Interface Segregation Principle: 接口 隔离 原则 
e Dependence Inversion Principle: 依赖 倒置 原则 


把 这 6 个 原则 的 首 字母 〈 里 氏 蔡 换 原则 和 迪 米 特 法 则 的 首 字 母 重 
复 ， 只 取 一 个 ) 联合 起 来 就 是 SOLID (solid， 稳 定 的 ) ， 其 代表 的 含义 
也 就 是 把 这 6 个 原则 结合 使 用 的 好 处 : 建立 稳定 、 灵 活 、 健 壮 的 设计 ， 
而 开 闭 原则 又 是 重 中 之 重 ， 是 最 基础 的 原则 ， 是 其 他 5 大 原则 的 精神 领 

















饥 。 我 们 在 使 用 开 团 原则 时 要 注意 以 下 儿 个 问题 。 





e 开 闭 原则 也 只 是 一 个 原则 


开 闭 原则 只 是 精神 口号 ， 实 现 拥抱 变化 的 方法 非常 多 ， 并 不 局 限于 
这 6 大 设计 原则 ， 但 是 遵循 这 6 大 设计 原则 基本 上 可 以 应 对 大 多 数 变化 。 
因此 ， 我 们 在 项 目 中 应 尽量 采用 这 6 大 原则 ， 适 当时 候 可 以 进行 扩充 ， 
例如 通过 类 文件 蔡 换 的 方式 完全 可 以 解决 系统 中 的 一 些 缺 陷 。 大 家 在 开 
发 中 比较 常用 的 修复 缺陷 的 方法 就 是 类 蔡 换 ， 比 如 一 个 软件 产品 已 经 在 
运行 中 ， 发 现 了 一 个 缺陷 ， 需 要 修正 怎么 办 ? 如果 有 自动 更 新 功能 ， 则 
可 以 下 载 一 个 .class 文 件 直接 履 盖 原 有 的 class， 重 新 启动 应 用 《也 不 一 定 
非 要 重新 启动 ) 就 可 以 解决 问题 ， 也 就 是 通过 类 文件 的 替换 方式 修正 了 
一 个 缺陷 ， 当 然 这 种 方式 也 可 以 应 用 到 项 目 中 ， 正 在 运行 中 的 项 目 发 现 
需要 增加 一 个 新 功能 ， 通 过 修改 原 有 实现 类 的 方式 就 可 以 解决 这 个 问 
题 ， 前 提 条 件 是 : 类 必须 做 到 高 内 聚 、 低 耦合 ， 否 则 类 文件 的 蔡 换 会 引 
起 不 可 预料 的 故障 。 
































e 项 目 规章 非常 重要 


如 末 你 是 一 位 项 目 经 理 或 架构 师 ， 应 尽量 让 自己 的 项 目 成 员 稳 定 ， 
稳定 后 才能 建立 高 效 的 团队 文化 ， 章 程 是 一 个 团队 所 有 成 员 共 同 的 知识 
结晶， 也 是 所 有 成 员 必须 遵守 的 约定 。 优 秀 的 章程 能 带 给 项 目 带 来 非常 
多 的 好 处 ， 如 提高 开发 效率 、 降 低 缺 陷 率 、 提 高 团队 士气 、 提 高 技术 成 








e 预知 变化 





在 实践 中 过 程 中 ， 架 构 师 或 项 目 经 理 一 旦 发 现 有 发 生变 化 的 可 能 ， 
或 者 变化 曾经 发 生 过 ， 则 需要 考虑 现 有 的 架构 是 否 可 以 轻松 地 实现 这 一 
变化 。 架 构 师 设计 一 套 系 统 不 仪 要 符合 现 有 的 需求 ， 还 要 适应 可 能 发 生 
的 变化 ， 这 才 是 一 个 优良 的 架构 。 


开 闭 原则 是 一 个 终极 目标 ， 任 何人 包括 大 师 级 人 物 都 无 法 百分之百 
做 到 ， 但 朝 这 个 方 同 努力 ， 可 以 非常 显 壮 地 改善 一 个 系统 的 染 构 ， 真 正 
做 到 “拥抱 变化 ”。 


第 二 部 分 “ 真 刀 实 枪 
一 一 23 种 设计 模式 完美 演绎 
单 例 模式 
工厂 方法 模式 
抽象 工厂 模式 





模板 方法 模式 
建造 者 模式 
代理 模式 





原型 模式 
中 介 者 模式 





命令 模式 
责任 链 模式 
装饰 模式 





打上 略 模式 
适配器 模式 
迭代 器 模式 
组 合 模式 
观察 者 模式 
门面 模式 


第 24 音 
第 25 章 
第 26 章 


第 27 章 


备 捷 录 模 式 
访问 者 模式 
状态 模式 

解释 器 模式 





第 28 章 


第 29 音 


诗 元 模式 


桥梁 模式 


第 7 草 ” 单 例 模 式 


7.1 我 是 星 带 我 独 盏 





目 从 秦 始 星 确立 了 星 带 这 个 位 置 以 后 ， 同 一 时 期 基本 上 就 只 有 一 个 
人 孤零零 地 坐 在 这 个 位 置 。 这 种 情况 下 臣民 们 也 好 处 理 ， 大 家 吨 拜 、 谈 
论 的 时 候 只 要 提 及 星 带 ， 每 个 人 都 知道 指 的 是 谁 ， 而 不 用 在 星 帝 前 面 加 
上 特定 的 称呼 ， 如 张 皇帝 、 李 皇帝 。 这 一 个 过 程 反 应 到 设计 领域 就 是 ， 
要 求 一 个 类 只 能 生成 一 个 对 象 〈 星 帝 ) ， 所 有 对 象 对 它 的 依赖 都 是 相同 
的 ， 因 为 只 有 一 个 对 象 ， 大 家 对 它 的 脾气 和 习性 都 非 第 了解， 建立 健壮 
稳固 的 关系 ， 我 们 把 星 帝 这 种 特殊 职业 通过 程序 来 实现 。 








星 帝 每 天 要 上 朝 接待 臣子 、 处 理 政务 ， 臣 子 每 天 要 印 拜 星 帝 ， 星 天 
只 能 有 一 个 ， 也 就 是 一 个 类 只 能 产生 一 个 对 象 ， 该 怎么 实现 呢 ? 对 象 产 
生 是 通过 new 关 键 字 完成 的 〈 当 然 也 有 其 他 方式 ， 比 如 对 象 复 制 、 反 射 
等 ) ， 这 个 怎么 控制 呀 ， 但 是 大 家 别 筷 记 了 构造 函数 ， 使 用 new 关 键 字 
创建 对 象 时 ， 都 会 根据 输入 的 参数 调用 相应 的 构造 函数 ， 如 果 我 们 把 构 
造 函 数 设置 为 private 私 有 访问 权限 不 束 可 以 茶 止 外 部 创建 对 象 了 吗 ? 蕊 
子 邑 拜 唯一 旦 和 带 的 过 程 类 图 如 图 7-1 所 示 。 




















-Emperor() 
+static Emperor getInstance() 
t+static Vold Say() 





图 7-1 臣子 吨 拜 星 帝 类 图 





只 有 两 个 类 ，Emperor 代 表 星 带 类 ，Minister 代 表 臣 子 类 ， 关 联 到 星 
帝 类 非常 简单 。Emperor 如 代码 清单 7-1 所 示 。 


代码 清单 7-1 皇帝 类 


public class Emperor { 
private static final Emperor emperor =new Emperor(); // 初 始 { 
private Emperor(){ 
// 世 俗 和 道德 约束 你 ， 目 的 就 是 不 希望 产生 第 二 个 旺 谊 








public static Emperor getInstance(){ 
return emperor,; 





} 

// 旦 帝 发 话 了 

public static void say()t{ 
System.out.println(" 我 就 是 皇帝 某 某 某 ,..."); 

} 


过 定义 一 个 私有 访问 权限 的 构造 浮 数 ， 避 人 免 被 其 他 类 new 出 来 一 
个 对 象 ， 而 Emperor 自己 则 可 以 new 一 个 对 象 出 来 ， 其 他 类 对 该 类 的 访问 
都 可 以 通过 getInstance 获 得 同一 个 对 象 。 


旦 第 有 了 ， 臣 子 要 出 场 ， 其 类 如 代码 清单 7-2 所 示 。 


代码 清单 7-2 臣子 类 


public class Minister { 
public static void main(String[|] args) { 
for(int day=0;day<3;day++){ 
Emperor emperor=Emperor.getInstance(); 
emperor .say(); 





} 
// 三 天 见 的 皇帝 都 是 同一 个 人 人， 荣幸 吧 ! 








臣子 参拜 星 帝 的 运行 结 采 如 下 所 示 。 











我 束 是 星 带 某 茶 某 … 











我 融 是 星 带 某 茶 菜 … 




















我 就 是 星 关 某 茶 某 .… 

臣子 天 天 要 上 参 参 见 明 带 ， 今 天 参拜 的 明 带 应 该 和 昨天、 前 天 的 一 
样 ( 过 渡 期 的 不 考虑 ， 别 找茬 哦 ) ， 大 臣 兢 完 尖 ， 拾 头 一 看 ， 嗨 ， 还 是 
昨天 那个 旦 弟 ， 老 熟人 人 了， 容易 讲话 ， 这 就 是 单 例 模 式 。 





7.2 单 例 蛋 云 的 定义 


单 例 模式 (Singleton Pattern ) 是 一 个 比较 简单 的 模式 ， 其 定义 如 
下 : 


Ensure a class has only one instance, and provide a global point of 


access to it.《〈 确 保 茶 一 个 类 只 有 一 个 实例 ， 而 且 目 行 实 例 化 并 加 整个 系 
统 提供 这 个 实例 。) 





单 例 模式 的 通用 类 图 如 图 7-2 所 示 。 






-static final Singleton singleton = new Singleton() 
-Smgleton() 


+static Singleton getSngleton() 










Client 


~ AN 加 ® > A 人 ~ 
通过 Singleton.getSingleton() 方 式 访问 





图 7-2 单 例 模式 通用 类 图 


Singleton 类 称 为 单 例 类 ， 通 过 使 用 private 的 构造 函数 确保 了 在 一 个 
应 用 中 只 产生 一 个 实例 ， 并 且 是 自行 实例 化 的 (在 Singleton 中 自己 使 用 
new Singleton0) 。 单 例 模式 的 通用 源 代 码 如 代码 清单 7-3 所 示 。 


代码 清单 7-3 单 例 模式 通用 代码 





public class Singleton { 
private static final Singleton singleton = new Singleton(); 
// 限 制 产 生 多 个 对 象 
private Singleton( ){ 














} 

// 通 过 该 方法 获得 实例 对 象 

public static Singleton getSingleton()t{ 
return singleton; 





} 

// 类 中 其 他 方法 ， 尽 量 是 static 

public static void doSomething(){ 
} 





7.3 单 例 模 式 的 应 用 


7.3.1 单 例 模 式 的 优点 


e 由 于 单 例 模式 在 内 存 中 只 有 一 个 实例 ， 减 少 了 内 存 开 文 ， 特 别 是 
一 个 对 象 需要 频 索 地 创建 、 销 毁 时 ， 而 且 创建 或 销毁 时 性 能 又 无 法 优 
化 ， 单 例 模式 的 优势 就 非常 明显 。 


e 由 于 单 例 模式 只 生成 一 个 实例 ， 所 以 减少 了 系统 的 性 能 开销 ， 妆 
一 个 对 象 的 产生 需要 比较 多 的 资源 时 ， 如 读 取 配置 、 产 生 其 他 依赖 对 象 
时 ， 则 可 以 通过 在 应 用 局 动 时 直接 产生 一 个 单 例 对 象 ， 然 后 用 永久 驻 留 
内 存 的 方式 来 解决 《在 Java EE 中 采用 单 例 模式 时 需要 注意 JVM 垃 圾 回 
收 机 制 ) 。 





e 单 例 模式 可 以 避免 对 资源 的 多 重 占 用 ， 例 如 一 个 写 文件 动作 ， 由 
于 只 有 一 个 实例 存在 内 存 中 ， 避 免 对 同一 个 资源 文件 的 同时 写 操作 。 





e 单 例 模 式 可 以 在 系统 设置 全 局 的 访问 点 ， 优 化 和 共 孚 资源 访问 ， 
例如 可 以 设计 一 个 单 例 类 ， 负 责 所 有 数据 表 的 映射 处 理 。 


7.3.2 单 例 模式 的 缺点 





e 单 例 模 式 一 般 没 有 接口 ， 扩 展 很 困难 ， 硝 要 扩展 ， 除 了 修改 代码 
基本 上 没有 第 二 种 途径 可 以 实现 。 单 例 模 式 为 什么 不 能 增加 接口 呢 ? 因 
为 接口 对 单 例 模 式 是 没有 任何 意义 的 ， 它 要 求 “ 自 行 实例 化 ”， 并 且 提 供 
单一 实例 、 接 口 或 抽象 类 是 不 可 能 被 实例 化 的 。 当 然 ， 在 特殊 情况 下 ， 
单 例 模式 可 以 实现 接口 、 被 继承 等 ， 需 要 在 系统 开发 中 根据 环境 判断 。 











e 单 例 借 式 对 训 试 是 不 利 的 。 在 并 行 开 发 环境 中 ， 如 采 单 例 模 式 没 
有 完成 ， 是 不 能 进行 测试 的 ， 没 有 接口 也 不 能 使 用 mock 的 方式 虚拟 一 
个 对 象 。 





e 单 例 模 式 与 单一 职 贡 原则 有 冲突 。 一 个 类 应 该 只 实现 一 个 逻辑 ， 
而 不 关心 它 是 否 是 单 例 的 ， 是 不 是 要 单 例 取决 于 环境 ， 单 例 模 式 把 “要 
单 例 ” 和 业务 逻辑 融合 在 一 个 类 中 。 


7.3.3 单 例 模式 的 使 用 场景 


下 一 个 系统 中 ， 要 求 一 个 类 有 且 仅 有 一 个 对 象 ， 如 果 出 现 多 个 对 象 
就 会 出 现 “ 不 恨 反 应 ?”， 可 以 采用 单 例 模 式 ， 有 具体 的 场景 如 下 : 





e 要 求生 成 唯一 序列 号 的 环境 ; 





e 在 整个 项 目 中 需要 一 个 共 储 访问 点 或 共享 数据 ， 例 如 一 个 Web 页 


面 上 的 计数 器 ， 可 以 不 用 把 每 次 刷新 都 记录 到 数据 库 中 ， 使 用 单 例 模式 


保持 计数 器 的 值 ， 并 确保 是 线程 安全 的 ; 


e 创建 一 个 对 象 需要 消耗 的 资源 过 多 ， 如 要 访问 IO 和 数据 库 等 资 
源 ; 








e 需要 定义 大 量 的 静态 常量 和 静态 方法 (如 工具 类 ) 的 环境 ， 可 以 
采用 单 例 模式 〈“ 当 然 ， 也 可 以 直接 声明 为 static 的 方式 ) 。 


7.3.4 单 例 模 式 的 注意 事项 
首先 ， 在 高 并 友情 况 下 ， 请 注意 单 例 模式 的 线程 同步 问题 。 单 例 模 


式 有 几 种 不 同 的 实现 方式 ， 上 面 的 例子 不 会 出 现 产 生 多 个 实例 的 情况 ， 
但 是 如 代码 清单 7-4 所 示 的 单 例 模 式 就 需要 考虑 线程 同步 。 





代码 清单 7-4 线程 不 安全 的 单 例 


public class Singleton { 
private static Singleton singleton = null; 
// 限 制 产生 多 个 对 象 
private Singleton(){ 








} 
// 通 过 该 方法 获得 实例 对 象 
public static Singleton getSingleton(){ 
if(singleton == null)t{ 
singleton = new Singleton(); 


return singleton; 


该 单 例 模 式 在 低 并 发 的 情况 下 沿 不 会 出 现 问题 ， 耕 系统 压力 增 大 ， 


并 发 量 增加 时 则 可 能 在 内 存 中 出 现 多 个 实例 ， 破 坏 了 最 初 的 预期 。 为 什 

会 出 现 这 种 情况 呢 ? 如 一 个 线程 A 执行 到 singleton = new Singleton()， 
但 还 没有 获得 对 象 〈 对 象 初始 化 是 需要 时 间 的 ) ， 第 二 个 线程 B 也 在 执 
行 ， 执 行 到 (singleton == null) 判断 ， 那 么 线程 B 获 得 判断 条 件 也 是 为 
真 ， 于 是 继续 运行 下 去 ， 线 程 A 获 得 了 一 个 对 象 ， 线 程 B 也 获得 了 一 个 
对 象 ， 在 内 存 中 就 出 现 两 个 对 象 ! 


A 








解决 线程 不 安全 的 方法 有 很 多 ， 可 以 在 getSingleton 方 法 前 加 
synchronized 关 键 字 ， 也 可 以 在 getSingleton 方 法 内 增加 synchronized 来 实 
现 ， 但 都 不 是 最 优秀 的 单 例 模 式 ， 建 议 读者 使 用 如 代码 清单 7-3 所 示 的 
方式 《有 的 书 上 把 代码 清单 7-3 中 的 单 例 称 为 饿 汉 式 单 例 ， 在 代码 清单 7- 
4 中 增加 了 synchronized 的 单 例 称 为 懒汉 式 单 例 ) 。 


其 次 ， 需 要 考虑 对 象 的 复制 情况 。 在 Java 中 ， 对 象 默认 是 不 可 以 被 
复制 的 ， 知 实现 了 Cloneable 接 口 ， 并 实现 了 clone 方 法 ， 则 可 以 直接 通 
过 对 象 复制 方式 创建 一 个 新 对 象 ， 对 象 复 制 是 不 用 调用 类 的 构造 函数 ， 
因此 即使 是 私有 的 构造 函数 ， 对 象 仍然 可 以 被 复制 。 在 一 般 情况 下 ， 类 
复制 的 情况 不 需要 考虑 ， 很 少 会 出 现 一 个 单 例 类 会 主动 要 求 被 复制 的 情 
况 ， 解 决 该 问题 的 最 好 方法 就 是 单 例 类 不 要 实现 Cloneable 接 口 。 

















7.4 单 例 模式 的 扩展 





如 果 一 个 类 可 以 产生 多 个 对 象 ， 对 象 的 数量 不 受 限 制 ， 则 是 非常 容 
易 实 现 的 ， 和 直接 使 用 new 关 键 字 就 可 以 了 ， 如 果 只 需要 一 个 对 象 ， 使 用 
单 例 模式 束 可 以 了 ， 但 是 如 果 要 求 一 个 类 只 能 产生 两 三 个 对 象 呢 ?该 怎 
么 实现 ? 我 们 还 以 呈 帝 为 例 来 说 明 。 


一 般 情 况 下 ， 一 个 朝代 的 同一 个 时 代 只 有 一 个 皇帝 ， 那 有 没有 出 现 
两 个 旺 帝 的 情况 呢 ? 确实 有 ， 就 出 现在 明 朝 ， 那 三 国 期 间 的 算 不 算 ? 不 
算 ， 各 自称 帝 ， 各 有 各 的 地 往 ， 国 号 不 同 。 大 家 还 记得 《石灰 吟 》 这 首 
诗 吗 ? 作者 是 谁 ? 于 谦 。 他 是 被 谁 杀 死 的 ? 明 英 守 朱 祁 镇 。 对 ， 就 是 那 
个 在 土木 堡 之 变 中 被 瓦 刺 俘虏 的 星 帝 ， 被 俘虏 后 ， 他 弟弟 朱 祁 钰 当 上 了 
时 第 ， 就 是 明 景 第 ， 估 计 刚 当 上 旦 帝 乐 疡 了 ， 访 记 把 他 哥哥 朱 祁 镇 升级 
为 太 上 量 ， 在 那个 时 期 就 出 现 了 两 个 星 帝 ， 这 期 间 的 大 丐 是 非常 郁 癌 
的 ， 为 什么 呀 ? 因为 可 能 出 现今 天 参拜 的 旺 帝 和 昨天 的 旺 帝 不 相同 ， 昨 
天 给 那个 明帝 汇报 ,今天 还 要 给 这 个 旦 第 汇 报 一 损 ， 该 情况 的 类 图 如 图 
7-3 所 示 。 














+static Int maxNumOfEmperor = 2 
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-Emperor() 

-Emperor(String name) 
+static Emperor getInstance() 
+static void say() 





maxNumOfEmperor 最 大 的 明之 数量 





图 7-3 多 个 皇帝 类 图 








这 个 类 图 看 起 来 还 算 简单 ， 但 是 实现 就 有 点 复杂 了 。Emperor 类 如 
代码 清单 7-5 所 示 。 











代码 清单 7-5 固定 数量 的 皇帝 类 


public class Emperor { 
// 定 义 最 多 能 产生 的 实例 数量 
private static int maxNumofEmperor = 2; 
// 每 个 皇帝 都 有 名 字 ， 使 用 一 个 ArrayList 来 容纳 ， 每 个 对 象 的 私有 属性 
private static ArrayList<String> nameList=new ArrayList<Stri 
// 定 义 一 个 列表 ， 容 纳 所 有 的 旺 帝 实例 
private static ArrayList<Emperor> emperorList=new ArrayList< 
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// 当 前 星 帝 序列 号 

private static int countNumofEmperor =0; 

// 产 生 所 有 的 对 象 

statict{ 
for(int i=0;i<maxNumOfEmperor;i++)t{ 

emperorList.add(new Emperor(" 星 "+(i+1)+" 帝 ") ) 

} 

} 


private Se 
// 世 俗 和 道德 约束 你 ， 目 的 就 是 不 产生 第 二 个 旦 各 
} 




















// 传 入 星 毅 名 称 ， 建 立 一 个 星 名 对象 
private Emperor(String name)t{ 
nameList.add(name); 








} 

// 随 机 获得 一 个 皇帝 对 象 

public static Emperor getInstance(){ 
Random random = new Random(); 
// 随 机 拉 出 一 个 旺 帝 ， 只 要 是 个 精神 领袖 就 成 
countNumofEmperor = random.nextInt(maxNumofEmperor ) ; 
return emperorList.get(countNumofEmperor ) ; 


} 
// 旦 第 发 话 了 
public static void say()t{ 
System.out ,println(nameList.get(countNumofEmperor ) ) ; 
} 


















































在 Emperor 中 使 用 了 两 个 ArrayList 分 别 存 储 实例 和 实例 变量 。 当 
然 ， 如 果 考 虑 到 线程 安全 问题 可 以 使 用 Vector 来 代 赫 。 臣 子 参 拜 星 帝 的 
过 程 如 代码 清单 7-6 所 示 。 


代码 清单 7-6 臣子 参拜 星 帝 的 过 程 


public class Minister { 
public static void main(String[] args) { 

// 定 义 5 个 大 臣 

int ministerNum =5; 

for(int i=0;i<ministerNum;i++){ 
Emperor emperor = Emperor.getInstance( ); 
System,out.print(" 第 "+(i+1)+" 个 大 臣 参 拜 的 是 : ") 
emperor .say(); 








大 臣 参 拜 星 帝 的 结果 如 下 所 示 。 





第 1 个 大 臣 参 拜 的 是 : 星 1 希 











第 2 个 大 臣 参 拜 的 是 : 星 2 各 





第 3 个 大 臣 参 拜 的 是 : 星 1 帝 





第 4 个 大 臣 参 拜 的 是 : 星 1 帝 











第 5 个 大 臣 参 拜 的 是 : 星 2 希 





看 ， 琳 然 每 个 大 臣 参 和 拜 的 旦 莹 都 可 能 不 一 样 ， 大 蕊 们 就 开始 糊涂 
了 ，A 大 臣 给 旦 1 营 汇 报 了 一 件 事情 ， 旦 2 各 不 知道 ， 然 后 束 开 始 怀疑 大 











臣 A 是 旦 1 篆 的 羔 信 ， 然 后 束 想 办 法 开始 整 .….…… 


这 种 需要 产生 固定 数量 对 象 的 模式 束 叫 做 有 上 限 的 多 例 模式 ， 它 是 
单 例 模 式 的 一 种 扩展 ， 采 用 有 上 限 的 多 例 模 式 ， 我 们 可 以 在 设计 时 决定 
在 内 存 中 有 多 少 个 实例 ， 方 便 系 统 进行 扩展 ， 修 正 单 例 可 能 存在 的 性 能 
问题 ， 提 供 系统 的 啊 应 速度 。 例 如 读 取 文件 ， 我 们 可 以 在 系统 局 动 时 完 
成 初始 化 工作 ， 在 内 存 中 启动 固定 数量 的 reader 实 例 ， 然 后 在 需要 读 取 








文件 时 就 可 以 快速 啊 应 。 


7.5 最 佳 实践 


单 例 模 式 是 23 个 模式 中 比较 简单 的 模式 ， 应 用 也 非常 广泛 ， 如 在 
Spring 中 ， 每 个 Bean 默 认 就 是 单 例 的 ， 这 样 做 的 优点 是 Spring 容 器 可 以 
管理 这 些 Bean 的 生命 期 ， 决 定 什么 时 候 创 建 出 来 ， 什 么 时 候 销 毁 ， 销 毁 
的 时 候 要 如 何 处 理 ， 等 等 。 如 果 采 用 非 单 例 模式 〈Prototype 类 型 ) ， 则 
Bean 初 始 化 后 的 管理 区 由 J2EE 容 髓 ，Spring 容 融 不 再 跟 踩 管 理 Bean 的 生 


命 周 期 。 





第 8 章 ”工厂 方法 模式 


8.1 女 娲 迄 人 的 故事 





东汉 《风俗 通 》 记 录 了 一 则 神话 故事 :“ 开 天 尽 地 ， 未 有 人 民 ， 女 
娲 搏 黄土 做 人 ”， 讲 述 的 内 容 就 是 大 家 非常 熟悉 的 女 如 造 人 的 故事 。 开 
天 尽 地 之 初 ， 大 地 上 并 没有 生物 ， 只 有 人 苍 藻 大 地 ， 纯 粹 而 洁净 的 自然 环 
境 ， 我 静 而 又 镍 寞 ， 于 是 女 娲 决定 创造 一 个 新 物种 〈 即 人 类 ) 来 增加 世 


界 的 索 染 ， 怎 么 制造 呢 ? 








别 志 了 女 娲 是 神仙 ， 没 有 办 不 到 的 事情 ， 造 人 的 过 程 是 这 样 的 ， 首 
先 ， 女 娲 采集 黄土 捏 成 人 的 形状 ， 然 后 放 到 八卦 炉 中 烧 制 ， 最 后 放置 到 
大 地 上 生长 ， 工 艺 过 程 是 没有 错 的 ， 但 是 意外 随时 都 会 发 生 : 





第 一 次 烤 泥 人 ， 感 觉 应 该 部 了 ， 往 大 地 上 一 放 ， 哇 ， 没 烤 熟 ! 于 是 
一 个 白人 诞生 了 ! (这 也 是 缺乏 经 验 的 最 好 证 明 。) 

第 二 次 烤 泥 人 ， 上 一 次 没 烤 熟 ， 这 次 多 烧 一 会 儿 ， 放 到 世间 一 看 ， 
嘿 ， 熟 过 头 了 ， 于 是 黑人 诞生 了 ! 





第 三 次 烤 泥 人 ， 一 边 烧 制 一 边 察看 ， 直 到 表皮 微 芮 ， 嘿 ， 刚 刚好 ， 
于 是 黄色 人 种 出 现 了 ! 











这 个 造 人 过 程 是 比较 有 意思 的 ， 是 不 是 可 以 通过 软件 开发 来 实现 这 
个 过 程 呢 ? 古人 云 :“ 三 人 行 ， 必 有 我 师 焉 ”， 在 面 癌 对 象 的 思维 中 ， 万 
物 缘 对 象 ， 是 对 象 我 们 惑 可 以 通过 软件 设计 来 实现 。 首 先 对 造 人 过 程 进 
行 分 析 ， 该 过 程 涉及 三 个 对 象 : 女 娲 、 八 卦 炉 、 三 种 不 同 肤色 的 人 。 女 
如 可 以 使 用 场景 类 Client 来 表示 ， 八 卦 炉 类 似 于 一 个 工厂 ， 负 员 制 造 生 
产 产品 ( 即 人 类 ) ， 三 种 不 同 肤 色 的 人 ， 他 们 都 是 同一 个 接口 下 的 不 同 
实现 类 ， 都 是 人 嘛 ， 只 是 肤色 、 语 言 不 同 ， 对 于 八卦 炉 来 说 都 是 它 生 产 
出 的 产品 。 分 析 完 毕 ， 我 们 束 可 以 画 出 如 图 8-1 所 示 的 类 图 。 














类 图 比较 简单 ，AbstractHumanFactory 是 一 个 抽象 类 ， 定 义 了 一 个 
八卦 炉 具有 的 整体 功能 ，HumanFactory 为 实现 类 ， 完 成 具体 的 任务 一 一 
创建 人 类 ; Human 接 口 是 人 类 的 总 称 ， 其 三 个 实现 类 分 别 为 三 类 人 种 ; 
NvWa 类 是 一 个 场景 类 ， 负 责 模拟 这 个 场景 执行 相关 的 任务 。 





我 们 定义 的 每 个 人 种 都 有 两 个 方法 : getColor〈 获 得 人 的 皮肤 颜 
色 ) 和 talk( 交 谈 ) ， 其 源 代 码 如 代码 清单 8-1 所 示 。 





<<interface>> 
Human 


AbPbstractHumanF actory 
一 一 一 = 一 
+Human createHuman({Class c) 


抽象 的 八卦 炉 


ee 
| 


tvoid getColor() 
Hvoid takk() 





黑色 种 蔚 色 人 和 | 白色 种 


图 8-1 女 娲 造 人 类 图 








代码 清单 8-1 人 类 总 称 


public interface Human { 

// 每 个 人 种 的 皮肤 都 有 相应 的 颜色 

public void getColor(); 

// 人 类 会 说 话 

public void talk(); 

接口 Human 是 对 人 类 的 总 称 ， 每 个 人 种 都 至 少 具 有 两 个 方法 ， 黑 色 
人 人 种、 黄色 人 种 、 白 色 人 种 的 代码 分 别 如 代码 清单 8-2、 代 码 清单 8-3、 


代码 清单 8-4 所 示 。 


代码 清单 8-2 黑色 人 种 





public class BlackHuman implements Human { 
public void getColor()t{ 
System.out.printlin(" 黑 色 人 种 的 皮肤 颜色 是 黑色 的 !")， 


} 
public void talk() { 
System.out.println(" 黑 人 会 说 话 ， 一 般 人 听 不 懂 。"); 





代码 清单 8-3 黄色 人 种 


public class YellowHuman implements Human { 
public void getColor()t{ 
System.out.println(" 黄 色 人 种 的 皮肤 颜色 是 黄色 的 !"); 















































} 
public void talk() { 

System.out.println(" 黄 色 人 种 会 说 话 ， 一 般 说 的 都 是 双 字 节 。") 
} 




















代码 清单 8-4 白色 人 种 


public class WhiteHuman implements Human { 
public void getColor()t{ 
System.out.println(" 白 色 人 种 的 皮肤 颜色 是 白色 的 !")， 

















} 
public void talk() { 

System,out,printlLn(" 白 色 人 种 会 说 话 ， 一 般 都 是 但 是 单字 节 。 
} 


“) 


ww 





所 有 的 人 种 定义 完毕 ， 下 一 步 束 是 定义 一 个 八卦 六 ， 然 后 烧 制 人 
类 。 我 们 想象 一 下 ， 女 娲 最 可 能 给 八卦 炉 下 达 什么 样 的 生产 命令 呢 ? 应 
该 是 “给 我 生产 出 一 个 黄色 人 种 (YellowHuman 类 ) ”， 而 不 会 是 “给 我 
生产 一 个 会 走 、 会 跑 、 会 说 话 、 皮 肤 是 黄色 的 人 种 ”， 因 为 这 样 的 命令 
增加 了 交流 的 成 本 ， 作 为 一 个 生产 的 管理 者 ， 只 要 知道 生产 什么 就 可 以 
了 ， 而 不 需要 事物 的 具体 信息 。 通 过 分 析 ， 我 们 发 现 八 卦 炉 生 产 人 类 的 
方法 输入 参数 类 型 应 该 是 Human 接 口 的 实现 类 ， 这 也 解释 了 为 什么 类 图 














上 的 AbstractHumanFactory 抽 象 类 中 createHuman 方 法 的 参数 为 Class 类 
型 。 其 源 代 码 如 代码 清单 8-5 所 示 。 


代码 清单 8-5 抽象 人 类 创建 工厂 


public abstract class AbstractHumanFactory { 
public abstract <T extends Human> T createHuman(Class<T> c); 


注意 ， 我 们 在 这 里 采用 了 泛 型 (Generic) ， 通 过 定义 泛 型 对 
createHuman 的 输入 参数 产生 两 层 限制 : 


e 必须 是 Class 类 型 ， 


e 必须 是 Human 的 实现 类 。 





其 中 的 "T" 表 示 的 是 ， 只 要 实现 了 Human 接 口 的 类 都 可 以 作为 参 
数 ， 泛 型 是 JDK 1.5 中 的 一 个 非常 重要 的 新 特性 ， 它 减少 了 对 象 间 的 转 
换 ， 约 束 其 输入 参数 类 型 ， 对 Collection 集 合 下 的 实现 类 都 可 以 定义 泛 
型 。 有 关 泛 型 的 详细 知识 ， 请 参考 相关 的 Java 语 法 文档 。 








目前 女 娲 只 有 一 个 八卦 护 ， 其 实现 生产 人 类 的 方法 ， 如 代码 清单 8- 
6 所 示 。 


代码 清单 8-6 人 类 创建 工厂 


public class HumanFactory extends AbstractHumanFactory { 
public <T extends Human> T createHuman(Class<T> c)t{ 
// 定 义 一 个 生产 的 人 种 





Human human=null; 


try { 
// 产 生 一 个 人 种 
human = (T)Class.forName(c.getName()).newIn 
} catch (Exception e) { 
System.out.println(" 人 种 生成 错误 !")， 


return (T)human; 





人 种 有 了 ， 八 卦 护 也 有 了 ， 剩 下 的 工作 就 是 女 娲 采集 黄土 ， 然 后 命 
令 八 卦 炉 开 始 生产 ， 其 过 程 如 代码 清单 8-7 所 示 。 


代码 清单 8-7 女 姗 类 


public class NVWa { 
public static void main(String[|] args) { 

// 声 明 阴阳 八卦 炉 
AbstractHumanFactory YinYangLu = new HumanFactory( ) ; 
// 女 娲 第 一 次 造 人 ， 火 候 不 足 ， 于 是 白人 产生 了 
System.out.println("-- 造 出 的 第 一 批 人 是 白色 人 种 --"); 
Human whiteHuman = YinYangLu.createHuman(WhiteHuman. 
whiteHuman.getColor(); 
whiteHuman.talk(); 
// 女 娲 第 二 次 造 人 ， 火 候 过 足 ， 于 是 黑人 产生 了 
System,out ， println("\n-- 造 出 的 第 二 批 人 是 黑色 人 种 - -")，; 
Human blackHuman = YinYangLu.createHuman(BlackHuman. 
blackHuman.getColor(); 
blackHuman. talk(); 
// 第 三 次 造 人 ， 火 候 刚 刚好 ， 于 是 黄色 人 种 产生 了 
System.out.println("\n-- 造 出 的 第 三 批 人 是 黄色 人 种 - -")，; 
Human yellowHuman = YinYangLu.createHuman(YellowHuma 
yellowHuman.getColor(); 
yellowHuman. talk( ); 





















































人 种 有 了 ， 八 卦 妨 有 了 ， 负 责 生产 的 女 娲 也 有 了 ， 激 动人 心 的 时 刻 
到 来 了 ， 我 们 运行 一 下 ， 结 果 如 下 所 示 。 


-- 造 出 的 第 一 批 人 是 白色 人 种 -- 


白色 人 种 的 皮肤 颜色 是 白色 的 ! 


白色 人 种 会 说 话 ， 一 般 都 是 单字 节 。 


-- 造 出 的 第 二 批 人 是 黑色 人 种 -- 


黑色 人 种 的 皮肤 颜色 是 黑色 的 ! 


黑人 会 说 话 ， 一 般 人 听 不 异 。 


-- 造 出 的 第 三 批 人 是 黄色 人 种 -- 


黄色 人 种 的 皮肤 颜色 是 黄色 的 ! 


黄色 人 种 会 说 话 ， 一 般 说 的 都 是 双 字 节 。 


哇 ， 人 类 的 生产 过 程 瑟 展现 出 来 了 ! 这 个 世界 就 热 曾 起 来 了 ， 黑 
人 、 昌 和信、 贰 人 都 开始 活动 了 ， 这 也 正 是 我 们 现在 的 真实 世界 。 以 上 整 
是 工厂 方法 模式 ( 没 错 ， 对 该 部 分 有 疑问 ， 请 继续 阅读 下 去 ) 。 





8.2 工厂 方法 模式 的 定义 
工厂 方法 模式 使 用 的 频率 非常 高 ， 在 我 们 日 常 的 开发 中 总 能 见 到 它 
的 身影 。 其 定义 为 : 


Define an interface for creating an object,but let subclasses decide which 
class to instantiate.Factory Method lets a class defer instantiation to 
subclasses.《 定 义 一 个 用 于 创建 对 象 的 接口 ， 让 子 类 决定 实例 化 哪 一 个 
类 。 工 广 方法 使 一 个 类 的 实例 化 延迟 到 其 子 类 。) 


工厂 方法 模式 的 通用 类 图 如 图 8-2 所 示 。 


Product 





\ 


ConcreteProduct| _ 





图 8-2 工厂 方法 模式 通用 类 图 


在 工厂 方法 模式 中 ， 抽 人 象 产品 类 Product 负 责 定 义 产品 的 共性 ， 实 现 
对 事物 最 抽象 的 定义 ; Creator 为 抽象 创建 类 ， 也 就 是 抽象 工厂 ， 有 具体 如 
何 创 建 产品 类 是 由 具体 的 实现 工厂 ConcreteCreator 完 成 的 。 工 厂 方法 模 


式 的 变种 较 多 ， 我 们 来 看 一 个 比较 实用 的 通用 源码 。 
抽象 产品 类 代码 如 代码 清单 8-8 所 示 。 


代码 清单 8-8 抽象 产品 类 


public abstract class Product { 
// 产 品类 的 公共 方法 
public void method1(){ 

// 业 务 逻 辑 处 理 


和 
// 抽 象 方法 
public abstract void method2() ; 
































具体 的 产品 类 可 以 有 多 个 ， 都 继承 于 抽象 产品 类 ， 其 源 代码 如 代码 
清单 8-9 所 示 。 


代码 清单 8-9 具体 产品 类 


public class ConcreteProduct1 extends Product { 
public void method2() { 
// 业 务 逻 辑 处 理 
} 


public class ConcreteProduct2 extends Product { 
public void method2() { 
// 业 务 逻 辑 处 理 
} 
























































抽象 工厂 类 负责 定义 产品 对 象 的 产生 ， 源 代码 如 代码 清单 8-10 所 


代码 清单 8-10 抽象 工厂 类 


public abstract class Creator { 
Wa 
* 创建 一 个 产品 对 象 ， 其 输入 参数 类 型 可 以 自行 设置 
* 通常 为 String、Enum、Class 等 ， 当 然 也 可 以 为 空 
*/ 
public abstract <T extends Product> T createpProduct(Class<T> 








具体 如 何 产 生 一 个 产品 的 对 象 ， 是 由 具体 的 工厂 类 实现 的 ， 如 代码 
清单 8-11 所 示 。 


代码 清单 8-11 具体 工厂 类 


public class ConcreteCreator extends Creator { 
public <T extends Product> T createProduct(Class<T> c)t{ 
Product product=null; 
try { 
product = (Product)Class.forName(c.getName()) 
} catch (Exception e) { 
// 异 常 处 理 























return (T)product; 


场景 类 的 调用 方法 如 代码 清单 8-12 所 示 。 


代码 清单 8-12 场景 类 


public class Client { 
public static void main(String[] args) { 
Creator creator = new ConcreteCreator(); 
Product product = creator.createProduct(ConcreteProd 
/* 
* 继续 业务 处 理 
*/ 























该 通用 代码 是 一 个 比较 实用 、 易 扩展 的 框架 ， 读 者 可 以 根据 实际 项 
目 需 要 进行 扩展 。 





8.3 工厂 方法 模式 的 应 用 


8.3.1 工厂 方法 模式 的 优点 


首先 ， 展 好 的 封装 性 ， 代 码 结构 清晰 。 一 个 对 象 创建 是 有 条 件 约束 
的 ， 如 一 个 调用 者 需要 一 个 具体 的 产品 对 象 ， 只 要 知道 这 个 产品 的 类 名 
《或 约束 字符 串 ) 就 可 以 了 ， 不 用 知道 创建 对 象 的 艰辛 过 程 ， 降 低 模块 
间 的 耦合 。 








工厂 方法 模式 的 扩展 性 非常 优秀 。 在 增加 产品 类 的 情况 下 ， 
只 要 适当 地 修改 具体 的 工厂 类 或 扩展 一 个 工 上 类 ， 就 可 以 完成 < 拥抱 变 
化 "”。 例 如 在 我 们 的 例子 中 ， 需 要 增加 一 个 标 色 人 种 ， 则 只 需要 增加 一 
个 BrownHuman 类 ， 工 厂 类 不 用 任何 修改 束 可 完成 系统 扩展 。 





再 次 ， 屏 蔽 产品 类 。 这 一 特点 非常 重要 ， 产 品类 的 实现 如 何 变化 ， 
调用 者 都 不 需要 关心 ， 它 只 需要 关心 产品 的 接口 ， 只 要 接口 保持 不 变 ， 
系统 中 的 上 层 模块 就 不 要 发 生变 化 。 因 为 产品 类 的 实例 化 工作 是 由 工 ) 
类 负责 的 ， 一 个 产品 对 象 具体 由 哪 一 个 产品 生成 是 由 工厂 类 决定 的 。 在 
数据 库 开 发 中 ， 大 家 应 该 能 够 深刻 体会 到 工厂 方法 模式 的 好 人 处， 如 果 使 
用 JDBC 连 接 数据 库 ， 数 据 库 从 MySQL 切 换 到 Oracle， 需 要 改动 的 地 方 
就 是 切换 一 下 驱动 名 称 〈 前 提 条 件 是 SQL 语句 是 标准 语句 ) ， 其 他 的 都 








不 需要 修改 ， 这 是 工 上 三 方法 模式 灵活 性 的 一 个 直接 案例 。 





最 后 ， 工 广 方法 模式 是 典型 的 解 灰 框 桨 。 高 层 模块 只 需要 知道 产品 
的 抽象 类 ， 其 他 的 实现 类 都 不 用 关心 ， 符 合 迪 米 特 法 则 ， 我 不 需要 的 就 
不 要 去 交流 ;也 符合 依赖 倒置 原则 ， 只 依赖 产品 类 的 抽象 ， 当 然 也 符合 
里 氏 从 换 原 则 ， 使 用 产品 子 类 丛 换 产品 父 类 ， 没 问题 ! 


8.3.2 工厂 方法 模式 的 使 用 场景 


首先 ， 工 三 方法 模式 是 new 一 个 对 象 的 丛 代 品 ， 所 以 在 所 有 需要 生 
成 对 象 的 地 方 都 可 以 使 用 ， 但 是 需要 慎重 地 考虑 是 人 否 要 增加 一 个 工厂 类 
进行 管理 ， 增 加 代码 的 复杂 上 度 。 





其 次 ， 需 要 灵活 的 、 可 扩展 的 框架 时 ， 可 以 考虑 采用 工厂 方法 模 
式 。 万 物 皆 对 象 ， 那 万 物 也 就 皆 产 品类 ， 例 如 需要 设计 一 个 连接 邮件 服 
务 器 的 框架 ， 有 三 种 网 络 协议 可 供 选 择 : POP3、IMAP、HITP， 我 们 
就 可 以 把 这 三 种 连接 方法 作为 产品 类 ， 定 义 一 个 接口 如 IConnectMail， 
然后 定义 对 邮件 的 操作 方法 ， 用 不 同 的 方法 实现 三 个 具体 的 产品 类 (也 
就 是 连接 方式 ) 再 定义 一 个 工厂 方法 ， 按 照 不 同 的 传 入 条 件 ， 选 择 不 同 
的 连接 方式 。 如 此 设计 ， 可 以 做 到 完美 的 扩展 ， 如 某 些 邮件 服务 器 提供 
了 WebService 接 口 ， 很 好 ， 我 们 只 要 增加 一 个 产品 类 就 可 以 了 。 











再 次 ， 工 三 方法 模式 可 以 用 在 寞 构 项 目 中 ， 例 如 通过 WebService 与 


一 个 非 Java 的 项 目 交 互 ， 虽 然 WebService 号 称 是 可 以 做 到 异 构 系统 的 同 
构 化 ， 但 是 在 实际 的 开发 中 ， 还 是 会 碰 到 很 多 问题 ， 如 类 型 问题 、 
WSDL 文 件 的 支持 问题 ， 等 等 。 从 WSDL 中 产生 的 对 象 都 认为 是 一 个 产 
品 ， 然 后 由 一 个 具体 的 工厂 类 进行 管理 ， 减 少 与 外 围 系 统 的 耦合 。 


最 后 ， 可 以 使 用 在 测试 驱动 开发 的 框架 下 。 例 如 ， 测 试 一 个 类 A， 
就 需要 把 与 类 A 有 关联 关系 的 类 B 也 同时 产生 出 来 ， 我 们 可 以 使 用 工厂 
方法 模式 把 类 B 虚 拟 出 来 ， 避 免 类 A 与 类 B 的 耦合 。 目 前 由 于 JMock 和 
EasyMock 的 诞生 ， 该 使 用 场景 已 经 弱化 了 ， 读 者 可 以 在 遇 到 此 种 情况 
时 直接 考虑 使 用 JMock 或 EasyMock。 














8.4 工厂 方法 模式 的 扩展 





工厂 方法 模式 有 很 多 扩展 ， 而 且 与 其 他 模式 结合 使 用 威力 更 大 ， 下 
面 将 介绍 4 种 扩展 。 


1. 缩小 为 简单 工厂 模式 


我 们 这 样 考虑 一 个 问题 : 一 个 模块 仅 需要 一 个 工厂 类 ， 没 有 必要 把 
它 产 生出 来 ， 使 用 静态 的 方法 就 可 以 了 ， 根 据 这 一 要 求 ， 我 们 把 上 例 中 
的 AbstarctHumanFactory 修 改 一 下 ， 类 图 如 图 8-3 所 示 。 








<<interface>> 
Human 





+static Human createHuman(Class c) 





+void talk() 








| 具体 的 八卦 炉 





BlackHuman YellowHuman White Human 


员 名 信和 白色 人 种 


图 8-3 简单 工厂 模式 类 图 


下 
+void getColor0[~……-| 人 类 | 


我 们 在 类 图 中 去 掉 了 AbstractHumanFactory 抽 象 类 ， 同 时 把 
createHuman 方 法 设置 为 静态 类 型 ， 简 化 了 类 的 创建 过 程 ， 变 更 的 源码 
仅仅 是 HumanFactory 和 NvWa 类 ，HumanFactory 如 代码 清单 8-13 所 示 。 


代码 清单 8-13 简单 工厂 模式 中 的 工厂 类 


public class HumanFactory { 
public static <T extends Human> T createHuman(Class<T> c){ 
// 定 义 一 个 生产 出 的 人 种 


Human human=null; 


try { 
i 
human = (Human)Class.forName(c.getName()).new 
} catch (Exception e) { 
System.out.println(" 人 种 生成 错误 !")， 





return (T)human; 


HumanFactory 类 仪 有 两 个 地 方 发 生变 化 :去 挥 继承 抽象 类 ， 并 在 
createHuman 前 增加 static 关 键 字 ; 工厂 类 发 生变 化 ， 也 同时 引起 了 调用 
者 NvWa 的 变化 ， 如 代码 清单 8-14 示 。 


代码 清单 8-14 简单 工厂 模式 中 的 场景 类 


public class NVWa { 
public static void main(String[] args) { 

// 女 娲 第 一 次 造 人 ， 火 候 不 足 ， 于 是 白色 人 种 产生 了 
System.out.println("-- 造 出 的 第 一 批 人 是 白色 人 种 --"); 
Human whiteHuman = HumanFactory.createHuman(WhiteHum 
whiteHuman.getColor(); 
whiteHuman.talk(); 
// 女 娲 第 二 次 造 人 ， 火 候 过 足 ， 于 是 黑色 人 种 产生 了 
System.out. println("\n-- 造 出 的 第 二 批 人 是 黑色 人 种 --")，; 
Human blackHuman = HumanFactory.createHuman(BlackHum 
blackHuman.getColor(); 




















blackHuman. talk( ); 

// 第 三 次 造 人 ， 火 候 刚 刚好 ， 于 是 黄色 人 种 产生 了 
System.out.println("\n-- 造 出 的 第 三 批 人 是 黄色 人 种 - -")，; 
Human yellowHuman = HumanFactory.createHuman(YellowH 
yellowHuman.getColor(); 

yellowHuman. talk( ); 
































运行 结果 没有 发 生变 化 ， 但 是 我 们 的 类 图 变 简单 了 ， 而 且 调 用 者 也 
比较 简单 ， 该 模式 是 工厂 方法 模式 的 弱化 ， 因 为 简单 ， 所 以 称 为 简单 工 
厂 模 式 (Simple Factory Pattern) ， 也 叫做 静态 工厂 模式 。 在 实际 项 目 
中 ， 采 用 该 方法 的 案例 还 是 比较 多 的 ， 其 缺点 是 工厂 类 的 扩展 比较 困 
难 ， 不 符合 开 闭 原则 ， 但 它 仍然 是 一 个 非常 实用 的 设计 模式 。 





2. 升级 为 多 个 工 类 


当 我 们 在 做 一 个 比较 复杂 的 项 目 时 ， 经 常会 遇 到 初始 化 一 个 对 象 很 
耗费 精力 的 情况 ， 所 有 的 产品 类 都 放 到 一 个 工厂 方法 中 进行 初始 化 会 使 
代码 结构 不 清晰 。 例 如 ， 一 个 产品 类 有 5 个 具体 实现 ， 每 个 实现 类 的 初 
始 化 〈 不 仅仅 是 new， 初 始 化 包括 new 一 个 对 象 ， 并 对 对 象 设置 一 定 的 
初始 值 》 方 法 都 不 相同 ， 如 果 写 在 一 个 工矿 方法 中 ， 势 必 会 导致 该 方法 
巨大 无 比 ， 那 该 怎么 办 ? 














考虑 到 需要 结构 清晰 ， 我 们 就 为 每 个 产品 定义 一 个 创造 者 ， 然 后 由 
调用 者 自己 去 选择 与 哪个 工厂 方法 关联 。 我 们 还 是 以 女 娲 造 人 为 例 ， 每 
个 人 种 都 有 一 个 固定 的 八卦 炉 ， 分 别 造 出 黑色 人 种 、 白 色 人 种 、 黄 色 人 
种 ， 修 改 后 的 类 图 如 图 8-4 所 示 。 


<<imterface>> 
Human 


+Vold getColor() 
+void talk() 
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tHuman createHuman!() 
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本 过 = 
创建 黑色 人 种 ”| 创建 黄色 人 种 】 ”| 创建 白色 人 种 
图 8-4 多 个 工厂 类 的 类 图 


每 个 人 种 “具体 的 产品 类 ) 都 对 应 了 一 个 创建 者 ， 每 个 创建 者 都 独 
芯 负 责 创建 对 应 的 产品 对 象 ， 非 常 符合 单一 职 贡 原则 ， 按 照 这 种 模式 我 
们 来 看 看 代码 变化 。 








多 工厂 模式 的 抽象 工厂 类 如 代码 清单 8-15 所 示 。 


代码 清单 8-15 多 工厂 模式 的 抽象 工厂 类 


public abstract class AbstractHumanFactory { 
public abstract Human createHuman(); 





注意 “抽象 方法 中 己 经 不 再 需要 传递 相关 参数 了 ， 因 为 每 一 个 具 
体 的 工矿 都 已 经 非常 明确 目 己 的 职责 : 创建 自己 负责 的 产品 类 对 象 。 











黑色 人 种 的 创建 工 三 如 代码 清单 8-16 所 示 。 


代码 清单 8-16 黑色 人 种 的 创建 工厂 实现 


public class BlackHumanFactory extends AbstractHumanFactory { 
public Human createHuman() { 
return new BlackHuman(); 
} 


黄色 人 种 的 创建 工厂 如 代码 清单 8-17 所 示 。 


代码 清单 8-17 黄色 人 种 的 创建 类 


public class YellowHumanFactory extends AbstractHumanFactory { 
public Human createHuman( ) { 
return new YellowHuman( ) ; 
} 


白色 人 种 的 创建 工厂 如 代码 清单 8-18 所 示 。 


代码 清单 8-18 白色 人 种 的 创建 类 


public class whiteHumanFactory extends AbstractHumanFactory { 
public Human createHuman() { 
return new WhiteHuman(); 
} 


三 个 具体 的 创建 工矿 都 非常 简单 ， 但 是 ， 如 果 一 个 系统 比较 复杂 时 
工厂 类 也 会 相应 地 变 复杂 。 场 景 类 NvWa 修 改 后 的 代码 如 代码 清单 8-19 
所 示 。 


代码 清单 8-19 场景 类 NvWa 


public class NvWwa { 
public static void main(String[|] args) { 

// 女 娲 第 一 次 造 人 ， 火 候 不 足 ， 于 是 白色 人 种 产生 了 
System.out.println("-- 造 出 的 第 一 批 人 是 白色 人 种 --"); 
Human whiteHuman = (new WhiteHumanFactory( )) ,createH 
whiteHuman.getColor(); 
whiteHuman.talk(); 
// 女 娲 第 二 次 造 人 ， 火 候 过 足 ， 于 是 黑色 人 种 产生 了 
System.out.println("\n-- 造 出 的 第 三 批 人 是 黑色 人 种 - -"); 
Human blackHuman = (new BlackHumanFactory()).createH 
blackHuman .getColor(); 
blackHuman.talk(); 
// 第 三 次 造 人 ， 火 候 刚 刚好 ， 于 是 黄色 人 种 产生 了 
System.out.println("\n-- 造 出 的 第 三 批 人 是 黄色 人 种 - -")，; 
Human yellowHuman = (new YellowHumanFactory()).creat 
yellowHuman.getColor(); 
yellowHuman. talk( ); 
























































结 末 还 是 相同 。 我 们 回顾 一 下 ， 每 一 个 产品 类 都 对 应 了 一 个 创 
， 好 处 就 是 创建 类 的 职责 清晰 ， 而 且 结构 简单 ， 但 是 给 可 扩展 性 和 
可 维护 性 带 来 了 一 定 的 影响 。 为 什么 这 么 说 呢 ? 如 果 要 扩展 一 个 产品 
类 ， 束 需要 建立 一 个 相应 的 工厂 类 ， 这 样 就 增加 了 扩展 的 难度 。 因 为 工 
三 类 和 产品 类 的 数量 相同 ， 维 护 时 需要 考虑 两 个 对 象 之 间 的 关系 。 





当然 ， 在 复杂 的 应 用 中 一 般 采 用 多 工厂 的 方法 ， 然 后 再 增加 一 个 协 
调 类 ， 避 人 免 调 用 者 与 各 个 子 工厂 交流 ， 协 调 类 的 作用 是 封装 子 工 厂 类 ， 


对 高 层 模块 提供 统一 的 访问 接口 。 


3. 将 代 早 例 模式 


第 7 章 讲 述 了 单 例 模式 以 及 扩展 出 的 多 例 模 式 ， 并 且 指 出 了 单 例 和 
多 例 的 一 些 缺 点 ， 我 们 是 不 是 可 以 采用 工厂 方法 模式 实现 单 例 模 式 的 功 
能 呢 ? 单 例 模 式 的 核心 要 求 束 是 在 内 存 中 只 有 一 个 对 象 ， 通 过 工厂 方法 














模式 也 可 以 只 在 内 存 中 生产 一 个 对 象 ， 类 图 如 图 8-5 所 示 。 


SingletonFactory 
-static Sngleton singleton 一 -| -Singleton0) 





图 8-5 工厂 方法 模式 蔡 代 单 例 模式 类 图 


非常 简单 的 类 图 ，Singleton 定 义 了 一 个 private 的 无 参 构 造 函 数 ， 目 
的 是 不 允许 通过 new 的 方式 创建 一 个 对 象 ， 如 代码 清单 8-20 所 示 。 


代码 清单 8-20 单 例 类 


public class Singleton { 
// 不 允许 通过 new 产 生 一 个 对 象 
private Singleton( ){ 


} 

public void doSomething()t{ 
// 业 务 处 理 

} 


Singleton 保 证 不 能 通过 正常 的 渠道 建立 一 个 对 象 ， 那 


SingletonFactory 如 何 建立 一 个 单 例 对 象 呢 ? 答案 是 通过 反射 方式 创建 ， 
如 代码 清单 8-21 所 示 。 


代码 清单 8-21 负责 生成 单 例 的 工厂 类 


public class SingletonFactory { 
private static Singleton singleton; 
statict{ 
try { 
Class cl= Class.forName(Singleton.class.getNa 
// 获 得 无 参 构 造 
Constructor constructor=cl.getDeclaredConstru 
// 设 置 无 参 构 造 是 可 访问 的 
constructor.setAccessible(true); 
// 产 生 一 个 实例 对 象 
singleton = (Singleton)constructor.newInstanc 
} catch (Exception e) { 
// 弄 向 处理 
} 


} 

public static Singleton getSingleton()t{ 
return singleton; 

} 























通过 获得 类 构造 器 ， 然 后 设置 访问 权限 ， 生 成 一 个 对 象 ， 然 后 提供 
外 部 访问 ， 保 证 内 存 中 的 对 象 叭 一。 当然 ， 其 他 类 也 可 以 通过 反射 的 方 
式 建立 一 个 单 例 对 象 ， 确 实 如 此 ， 但 是 一 个 项 目 或 团队 是 有 章程 和 规范 
的 ， 何 况 已 经 提供 了 一 个 获得 单 例 对 象 的 方法 ， 为 什么 还 要 重新 创建 一 
个 新 对 象 呢 ? 除非 是 有 人 作恶 。 





以 上 通过 工厂 方法 模式 创建 了 一 个 单 例 对 象 ， 该 框架 可 以 继续 扩 
展 ， 在 一 个 项 目 中 可 以 产生 一 个 单 例 构造 占 ， 所 有 需要 产生 单 例 的 类 都 
遵循 一 定 的 规则 (构造 方法 是 private)， 然 后 通过 扩展 该 框架 ， 只 要 输 





入 一 个 类 型 就 可 以 获得 唯一 的 一 个 实例 。 
4. 延迟 初始 化 


何 为 延迟 初始 化 〈Lazy initialization ) ? 一 个 对 象 被 消费 完毕 后 ， 
并 不 立刻 释放 ， 工 三 类 保持 其 初始 状态 ， 等 竺 再 次 被 使 用 。 延 迟 初始 化 
是 工厂 方法 模式 的 一 个 扩展 应 用 ， 其 通用 类 图 如 图 8-6 所 示 。 


Product 


+static final Map<String,Product> prMap = new HashMap() 
> 5 +void doSomeithing!) 
+static synchronized Product createProduct(Strng type) - 


ConcreteProduct 





图 8-6 延迟 初始 化 的 通用 类 图 


ProductFactory 负 责 产 品类 对 象 的 创建 工作 ， 并 且 通 过 prMap 变 量 产 
生 一 个 缓存 ， 对 需要 再 次 被 重用 的 对 象 保留 ，Product 和 ConcreteProduct 
是 一 个 示例 代码 ， 请 参考 代码 清单 8-8 和 代码 清单 8-9。ProductFactory 如 
代码 清单 8-22 所 示 。 


代码 清单 8-22 延迟 加 载 的 工厂 类 


public class ProductFactory { 
private static final Map<String,Product> prMap = new HashMap 
public static synchronized Product createProduct(String typ 
Product product =null; 


// 如 果 Map 中 己 经 有 这 个 对 和 象 
if(prMap.containskKey(type))t 
product = prMap.get(type); 





}elsef 
if(type.equals("Product1"))t{ 
product = new ConcreteProduct1(); 
}elsef 
product = new ConcreteProduct2(); 


} 
// 同 时 把 对 象 放 到 缓存 容器 中 
prMap.put(type,product); 


return product; 





代码 还 比较 简单 ， 通 过 定义 一 个 Map 容 器 ， 容 纳 所 有 产生 的 对 象 ， 
如 果 在 Map 容 避 中 已 经 有 的 对 象 ， 则 直接 取出 返回 ; 如 果 没 有 ， 则 根据 
需要 的 类 型 产生 一 个 对 象 并 放 入 到 Map 容 吕 中 ， 以 方便 下 次 调用 。 


延迟 加 载 框架 是 可 以 扩展 的 ， 例 如 限制 某 一 个 产品 类 的 最 大 实例 化 
数量 ， 可 以 通过 判断 Map 中 己 有 的 对 象 数量 来 实现 ， 这 样 的 处 理 是 非常 
有 意义 的 ， 例 如 JDBC 连 接 数据 库 ， 都 会 要 求 设 置 一 个 MaxConnections 
最 大 连接 数量 ， 该 数量 就 是 内 存 中 最 大 实例 化 的 数量 。 











延迟 加 载 还 可 以 用 在 对 象 初始 化 比较 复杂 的 情况 下 ， 例 如 硬件 访 
问 ， 涉 及 多 方面 的 交互 ， 则 可 以 通过 延迟 加 载 降 低 对 象 的 产生 和 销毁 带 
来 的 复杂 性 。 


8.5 最 住 实践 





工厂 方法 模式 在 项 目 中 使 用 得 非常 频 紧 ， 以 至 于 很 多 代码 中 都 包含 
工厂 方法 模式 。 该 模式 几乎 尽 人 皆 知 ， 但 不 是 每 个 人 都 能 用 得 好 。 熟 能 
生 巧 ,熟练 掌握 该 模式 ， 多 思考 工厂 方法 如 何 应 用 ， 而 且 工 厂 方法 模式 
还 可 以 与 其 他 模式 混合 使 用 例如 模板 方法 模式 、 单 例 柑 式 、 原 型 模式 
等 ) ， 变 化 出 无 穷 的 优秀 设计 ， 这 也 正 是 软件 设计 和 开发 的 乐趣 所 在 。 


第 9 章 ”抽象 工厂 模式 


9.1 女 娲 的 失误 


第 8 章 讲 了 女 娲 造 人 的 故事 。 人 有 是 造 出 来 了 ， 世 界 也 热 疝 了 ， 可 是 
低头 一 看 ， 都 是 清一色 的 类 型 ， 缺 少 关 爱 、 仇 恨 、 喜 和 低 素 乐 等 情绪 ， 人 
类 的 生命 太平 淡 了 ， 女 娲 一 想 ， 狐 然 一 拍 脑袋 ， 还 记 给 人 类 定义 性 别 
了 ， 那 怎么 办 ? 抹 掉 重 来 ， 于 是 人 类 经 过 一 次 大 洗礼 ， 所 有 的 人 种 都 消 
灭 挥 了， 世界 又 是 空 无 一 物 ， 我 静 而 义 我 宽 。 





由 于 女 娲 之 前 的 准备 工作 花费 了 非 第 大 的 精力 ， 比 如 准备 黄土 、 八 
卦 炉 等 ， 从 头 开始 建立 所 有 的 事物 也 是 不 可 能 的 ， 那 就 想 在 现 有 的 条 件 
下 重新 造 人 ， 尺 可 能 旧 物 利用 嘛 。 人 种 (Product 产 品类 ) 应 该 怎么 改造 
呢 ? 怎么 才能 让 人 类 有 爱 有 恨 呢 ? 古 神 仙 当 然 有 办 法 了 ， 定 义 互 斥 的 性 
别 ， 然 后 在 每 个 个 体 中 埋 下 一 条 种 子 : 异性 相 吸 ， 成 熟 后 就 一 定 会 去 找 
个 异性 〈 这 就 是 我 们 说 的 爱情 原动力 ) 。 从 设计 角度 来 看 ， 一 个 具体 的 
对 象 通过 两 个 坐标 就 可 以 确定 : 肤色 和 性 别 ， 如 图 9-1 所 示 。 





女 男 性 判 


图 9-1 肤色 性 别 坐 标 图 





产品 类 分 析 完 毕 了 ， 生 产 的 工厂 类 (八卦 炉 ) 该 怎么 改造 呢 ? 只 有 
一 个 生产 设备 ， 要 么 生产 出 来 的 全 都 是 男性 ， 要 么 都 是 女性 。 那 不 行 
呀 ， 这 么 翻天 宪 地 的 改造 就 是 为 了 产生 不 同性 别 的 人 类 。 有 办 法 了 ! 把 
目前 已 经 有 的 生产 设备 一 一 八卦 炉 拆 开 ， 于 是 女 娲 就 使 用 了 “八卦 复制 
术 ”， 把 原先 的 八卦 炉 一 个 变 两 个 ， 并 且 略 加 修改 ， 残 成 了 女性 八卦 炉 
《只 生产 女性 人 种 ) 和 男性 八卦 炉 ( 只 生产 男性 人 种 〉， 于 是 乎 女 娲 就 
开始 准备 生产 了 ， 其 类 图 如 图 9-2 所 示 。 


这 个 类 图 虽然 大 ， 但 是 比较 简单 。Java 的 典型 类 图 ， 一 个 接口 ， 多 
个 抽象 类 ， 然 后 是 N 个 实现 类 ， 每 个 人 种 都 是 一 个 抽象 类 ， 性 别 是 在 各 
个 实现 类 中 实现 的 。 特 别 需 要 说 明 的 是 HumanFactory 接 口 ， 在 这 个 接口 





中 定义 了 三 个 方法 ， 分 别 用 来 生产 三 个 不 同 肤色 的 人 种 ， 也 就 是 我 们 在 
图 9-1 中 的 Y 坐 标 ， 它 的 两 个 实现 类 分 别 是 性 别 ， 也 就 是 图 9-1 中 的 X 坐 

标 ， 通 过 X 坐 标 〈 性 别 ) 和 Y 坐 标 〈 肤 色 ) 唯一 确定 了 一 个 生产 出 来 的 

对 象 。 我 们 来 看 看 相关 的 实现 ，Human 接 口 如 代码 清单 9-1 所 示 。 


<<mterface>> 
Human 


tvold getColor() 
tvoid talk)) 
+void getSex() 





人 : A 
AbstractBlack Human AbstractWhiteHuman AbstractYellowH uman 



















tvowd getColor() tvoid getColor() +void getColor() 
+Vok talk() +void talk() +void takk() 


FemaleBlackHuman 
== 二 一 一 二 二 = 


tvoid getSex() 







MaleBlackHuman 
| 


tvoid getSex() 






<<interface>> 
HumanFactory 


HHuman createY ellowHuman() 


+Human createWhiteHuman() 
HHuman createBlackHuman() 





Female Factory MaleFactory 
= 上 === 二 








图 9-2 女 娲 重新 生产 人 类 


代码 清单 9-1 人 种 接口 


public interface Human { 


// 每 个 人 种 都 有 相应 的 颜色 
public void getColor(); 
// 人 类 会 说 话 

public void talk(); 

// 每 个 人 都 有 性 别 

public void getSex(); 











人 种 有 三 个 抽象 类 ， 负 责 人 种 的 抽象 属性 定义 : 肤色 和 语言 。 和 白色 


人 种 、 黑 色 人 种 、 黄 色 人 种 分 别 如 代码 清单 9-2、 代 码 清单 9-3、 代 码 清 


单 9-4 所 示 。 


代码 清单 9-2 白色 人 种 


public abstract class AbstractwhiteHuman implements Human { 
// 白 色 人 种 的 皮肤 颜色 是 白色 的 
public void getColor()t{ 

System.out.println(" 白 色 人 种 的 皮肤 颜色 是 白色 的 !")， 


} 
// 白 色 人 种 讲话 
public void talk() { 


} 



































System,out,println(" 白 色 人 种 会 说 话 ， 一 般 说 的 都 是 单字 节 。 





代码 清单 9-3 黑色 人 种 


public abstract class AbstractBlackHuman implements Human { 


public void getColor(){ 
System.out.println(" 黑 色 人 种 的 皮肤 颜色 是 黑色 的 !")，; 


忆 























} 

public void talk() { 
System.out.println(" 黑 人 会 说 话 ， 一 般 人 听 不 懂 。"); 

} 





代码 清单 9-4 黄色 人 种 


public abstract class AbstractYellowHuman implements Human { 


") 


public void getColor()t{ 
System.out .println(" 黄 色 人 种 的 皮肤 颜色 是 黄色 的 ! ") ; 















































} 
public void talk() { 

System.out.println(" 黄 色 人 种 会 说 话 ， 一 般 说 的 都 是 双 字 节 。") 
} 





























每 个 抽象 类 都 有 两 个 实现 类 ， 分 别 实现 公共 的 最 细节 、 最 具体 的 事 
物 : 肤色 和 语言 。 有 具体 的 实现 类 实现 肤色 、 人 性 别 定义 ， 以 黄色 女性 人 种 
为 例 ， 如 代码 清单 9-5 所 示 。 


代码 清单 9-5 黄色 女性 人 种 


public class FemaleYellowHuman extends AbstractYellowHuman { 
// 黄 人 女性 
public void getSex() { 
System,out.printlLn(" 黄 人 女性 ") ， 
} 
































黄色 男性 人 种 如 代码 清单 9-6 所 示 。 


代码 清单 9-6 黄色 男性 人 种 





public class MaleYellowHuman extends AbstractYellowHuman { 
// 黄 人 男性 


























public void getsex() { 
System.out.printlin(" 黄 人 男性 ")， 
} 





























其 他 的 黑色 人 种 、 和 白色 人 种 的 男性 和 女性 的 代码 与 此 类 似 ， 不 再 重 
复 编写 。 到 此 为 止 ， 我 们 已 经 把 真实 世界 的 人 种 都 定义 出 来 了 ， 剩 下 的 
工作 就 是 怎么 制造 人 类 。 接 口 HumanFactory 如 代码 清单 9-7 所 示 。 


代码 清单 9-7 八卦 炉 定义 


public interface HumanFactory { 





// 制 造 
public 


个 黄色 人 种 


Human createYellowHuman(); 

















// 制 造 
public 











// 制 造 
public 


个 白色 人 种 
Human createwhiteHuman(); 
个 黑色 人 种 


Human createBlackHuman(); 








在 接口 中 ， 我 们 看 到 八卦 炉 是 可 以 生产 出 不 同 肤 色 人 种 的 (当然 
了 ， 女 娲 的 失误 嘛 ) ， 那 它 有 多 少 个 八卦 炉 昵 ? 两 个 ， 分 别 生产 女性 和 
男性 ， 女 性 和 男性 八卦 炉 分 别 如 代码 清单 9-8 和 代码 清单 9-9 所 示 。 


代码 清单 9-8 生产 女性 的 八卦 炉 


public class FemaleFactory implements HumanFactory { 


// 生 产 出 黑人 女性 


public 





Human createBlackHuman() { 
return new FemaleBlackHuman( ); 


7 
// 生 产 出 白人 女性 


public 


Human createwhiteHuman() { 
return new FemalewhiteHuman(); 





} 
// 生 产 出 黄 人 女性 


public Human createYellowHuman() { 


i 














return new FemaleYellowHuman( ); 


代码 清单 9-9 生产 男性 的 八卦 炉 


public class MaleFactory implements HumanFactory { 
// 生 产 出 黑人 男性 


public Human createBlackHuman() { 




















return new MaleBlackHuman( ) ; 








} 
// 生 产 出 白人 男性 











public Human createwhiteHuman( ) { 


return new MalewhiteHuman( ) ; 





























// 生 产 出 i 


黄 人 男性 


public Human createYellowHuman() { 


$ 


人 种 有 了 ， 


return new MaleYellowHuman( ); 


八卦 炉 也 有 了 ， 我 们 就 来 重 现 一 下 当年 女 娲 造 人 的 光 


景 ， 如 代码 清单 9-10 所 示 。 


代码 清单 9-10 女 如 重 造 人 类 


public class 


NVWa { 

















public static void main(String[] args) { 
我 


// 第 一 条 和 生产线， 男性 生产 

HumanFactory maleHumanFactory = new MaleFactory(); 
// 第 二 条 生产 线 ， 女 性 生产 线 

HumanFactory femaleHumanFactory = new FemaleFactory( 
// 生 产 线 建立 完毕 ， 开 始 生 产 人 了 : 

Human maleYellowHuman = maleHumanFactory.createYello 
Human femaleYellowHuman = femaleHumanFactory.createY 
System.out.println("--- 生 产 一 个 黄色 女性 ---")， 
femaleYellowHuman.getColor(); 
femaleYellowHuman. talk( ); 
femaleYellowHuman.getSex(); 
System.out.println("\n--- 生 产 一 个 黄色 男性 ---"); 
maleYellowHuman.getColor(); 

maleYellowHuman.talk(); 

maleYellowHuman.getSex( ) ; 
























































we 
* 后 面 继续 创建 
*/ 
} 
} 
运行 结果 如 下 所 示 : 








-生产 一 个 黄色 女性 --- 


























黄色 人 种 的 皮肤 颜色 是 黄色 的 ! 












































黄色 人 种 会 说 话 ， 一 般 说 的 都 是 双 字 节 























-生产 一 个 黄色 男性 --- 
































黄色 人 种 的 皮肤 颜色 是 黄色 的 ! 









































黄色 人 种 会 说 话 ， 一 般 说 的 都 是 双 字 节 


























各 种 肤色 的 男性 、 女 性 都 制造 出 来 了 ， 两 性 之 间 产 生 了 相互 吸引 
力 ， 于 是 情感 产生 ， 这 个 世界 就 多 了 一 种 小 说 的 题材 “爱情 ?。 回 头 来 想 
想 我 们 的 设计 ， 不 知道 大 家 有 没有 去 过 工厂 ， 每 个 工 三 分 很 多 车 间 ， 每 
个 车 间 又 分 多 条 生产 线 ， 分 别 生产 不 同 的 产品 ， 我 们 可 以 把 八卦 炉 比 喻 
为 守 闻 ;把 从 卦 如 生 户 的 二 认 生产 日 x 吉大 还 是 贡 信 7》 称 为 生产 
线 ， 如 此 来 看 就 是 一 个 女性 生产 车 间 ， 专 门生 产 各 种 肤色 的 女性 ， 一 
是 男性 生产 车 间 ， 专 门生 产 各 种 肤色 男性 ， 生 产 完毕 就 可 以 在 系统 外 组 
装 ， 什 么 是 组 装 ? 嘿 虽 ， 目 己 思考 ! 在 这 样 的 设计 下 ， 各 个 车 间 和 各 条 
生产 线 的 职 贡 非常 明确 ， 在 车 间 内 各 个 生产 出 来 的 产品 可 以 有 耦合 关 
系 ， 你 要 知道 世界 上 黑 、 黄 、 白 人 种 的 比例 是 : 1 : 4 : 6， 那 这 就 需 
女 如 奶奶 在 烧 制 的 时 候 就 要 做 好 比例 分 配 ， 在 一 个 车 间 内 协调 好 。 这 就 
是 抽象 工厂 模式 。 














9.2 抽象 工厂 模式 的 定义 
抽象 工厂 模式 (Abstract Factory Pattern ) 是 一 种 比较 常用 的 模式 ， 
其 定义 如 下 : 


Provide an interface for creating families of related or dependent objects 
without specifying their concrete classes. (为 创建 一 组 相关 或 相互 依赖 的 
对 象 提 供 一 个 接口 ， 而 且 无 须 指 定 它们 的 有 具体 类 。 ) 


抽象 工厂 模式 的 通用 类 图 如 图 9-3 所 示 。 


AbstractFactory AbstractProduct 


tHCreateProduct() 


ConcreteFactory | ConcreteProduct 





图 9-3 抽象 工厂 模式 的 通用 类 图 


抽象 工厂 模式 是 工厂 方法 模式 的 升级 版 本 ， 在 有 多 个 业务 品种 、 业 
务 分 类 时 ， 通 过 抽象 工厂 模式 产生 需要 的 对 象 是 一 种 非常 好 的 解决 方 
式 。 我 们 来 看 看 抽象 工矿 的 通用 源 代码 ， 首 先 有 两 个 互相 影响 的 产品 线 
《也 叫做 产品 族 ) ， 例 如 制造 汽车 的 左 侧门 和 右 侧门 ， 这 两 个 应 该 是 数 
量 相等 的 一 一 两 个 对 象 之 间 的 约束 ， 每 个 型 号 的 车 门 都 是 不 一 样 的 ， 这 
是 产品 等 级 结构 约束 的 ， 我 们 先 看 看 两 个 产品 族 的 类 图 ， 如 图 9-4 所 
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ApbstractProductA 





i 


AbstractCreator 





ened ssid 
| 


图 9-4 抽象 工厂 模式 的 通用 源码 类 图 


注意 类 图 上 的 圈 圈 、 框 框 相对 应 ， 两 个 抽象 的 产品 类 可 以 有 关系 ， 
例如 共同 继承 或 实现 一 个 抽象 类 或 接口 ， 其 源 代 码 如 代码 清单 9-11 所 


钞 。 





代码 清单 9-11 抽象 产品 类 


public abstract class AbstractProductA { 











// 每 个 产品 共有 的 方法 
public void shareMethod (){ 








} 
// 每 个 产品 相同 方法 ， 不 同 实现 
public abstract void doSomething() ， 


两 个 具体 的 产品 实现 类 如 代码 清单 9-12、 代 码 清单 9-13 所 示 。 


代码 清单 9-12 产品 A1 的 实现 类 


public class ProductA1 extends AbstractProductA { 
public void doSomething() { 
System.out.printLn(" 产 品 AL 的 实现 方法 " ) ; 
} 





代码 清单 9-13 产品 A2 的 实现 类 


public class ProductA2 extends AbstractProductA { 
public void doSomething() { 
System.out.println(" 产 品 A2 的 实现 方法 ")，; 





产品 B 与 此 类 似 ， 不 再 歼 述 。 抽 象 工厂 类 AbstractCreator 的 职责 是 定 
义 每 个 工厂 要 实现 的 功能 ， 在 通用 代码 中 ， 抽 象 工厂 类 定义 了 两 个 产品 
族 的 产品 创建 ， 如 代码 清单 9-14 所 示 。 





代码 清单 9-14 抽象 工厂 类 


public abstract class AbstractCreator { 
// 创 建 A 产 品 家 族 
public abstract AbstractProductA createProductA( ); 
// 创 建 B 产 品 家 族 
public abstract AbstractProductB createProductB( ); 

















注意 ”有 NN 个 产品 族 ， 在 抽象 工厂 类 中 就 应 该 有 NN 个 创建 方法 。 








如 何 创 建 一 个 产品 ， 则 是 由 具体 的 实现 类 来 完成 的 ，Creator1 和 
Creator2 如 代码 清单 9-15 和 代码 清单 9-16 所 示 。 


代码 清单 9-15 产品 等 级 1 的 实现 类 


Po class Creator1 extends AbstractCreator { 
只 生产 产品 等 级 为 1 的 A 产品 
or AbstractProductA createProductA() { 
return new ProductA1( ); 


只 生产 产品 等 级 为 1 的 B 产 品 
or AbstractProductB createProductB() { 
return new ProductB1(); 
} 


代码 清单 9-16 产品 等 级 2 的 实现 类 


public class Creator2 extends AbstractCreator { 
// 只 生产 产品 等 级 为 2 的 A 产品 
public AbstractProductA createProductA() { 
return new ProductA2( ); 


// 只 生产 产品 等 级 为 2 的 B 产 品 

public AbstractProductB createProductB() { 
return new ProductB2( ); 

} 











注意 ”有 M 个 产品 等 级 就 应 该 有 M 个 实现 工厂 类 ， 在 每 个 实现 工 ) 
中 ， 实 现 不 同 产 品 族 的 生产 任务 。 





在 有 具体 的 业务 中 如 何 产生 一 个 与 实现 无 关 的 对 象 呢 ? 如 代码 清单 9- 
17 上 所 示 。 


代码 清单 9-17 场景 类 


public class Client { 

public static void main(String[] args) { 
// 定 义 出 两 个 工厂 
AbstractCreator creator1 
AbstractCreator creator2 
// 产 生 A1 对 象 
AbstractProductA ai = creator1l.createProductA( ) ; 
// 产 生 A2 对 象 
AbstractProductA a2 = creator2.createProductA( ) ; 
// 产 生 B1 对 象 
AbstractProductB b1 = creator1.createProductB( ) ; 
// 产 生 B2 对 象 
AbstractProductB b2 = creator2.createProductB( ) ; 

* 


* 然后 在 这 里 就 可 以 为 所 欲 为 了 ... 


* 





new Creator1( ) ; 
new Creator2( ) ; 








在 场景 类 中 ， 没 有 任何 一 个 方法 与 实现 类 有 关系 ， 对 于 一 个 产品 来 
说 ， 我 们 只 要 知道 它 的 工厂 方法 束 可 以 直接 产生 一 个 产品 对 象 ， 无 须 关 
心 它 的 实现 类 。 





9.3 抽象 工厂 模式 的 应 用 


9.3.1 抽象 工厂 模式 的 优点 














e 封 效 性， 每 个 产品 的 实现 类 不 是 高 层 模 块 要 关心 的 ， 它 要 关心 的 
是 什么 ”是 接口 ， 是 抽象 ， 它 不 关心 对 象 是 如 何 创 建 出 来 ， 这 由 谁 负责 
昵 ? 工 三 类 ， 只 要 知道 工厂 类 是 谁 ， 我 束 能 创建 出 一 个 需要 的 对 象 ， 省 
时 省 力 ， 优 秀 设计 就 应 该 如 此 。 





e 产品 族 内 的 约束 为 非 公 开 状态 。 例 如 生产 男女 比例 的 问题 上 ， 猜 
想 女 姻 尹 女 肯 定 有 上 自己 的 打算 ， 不 能 让 女 盛 男 脆 ， 人 否则 女性 的 优 扣 不 下 
体现 不 出 来 了 吗 ? 那 在 抽象 工厂 模式 ， 束 应 该 有 这 样 的 一 个 约束 : 每 生 
产 1 个 女性 ， 就 同时 生产 出 1.2 个 男性 ， 这 样 的 生产 过 程 对 调用 工厂 类 的 
高 层 模块 来 说 是 透明 的 ， 它 不 需要 知道 这 个 约束 ， 我 就 是 要 一 个 黄色 女 
性 产品 束 可 以 了 ， 具 体 的 产品 族 内 的 约束 是 在 工厂 内 实现 的 。 








9.3.2 抽象 工厂 模式 的 缺点 


抽象 工厂 模式 的 最 大 缺点 就 是 产品 族 扩展 非 第 困难 ， 为 什么 这 么 说 
呢 ? 我 们 以 通用 代码 为 例 ， 如 果 要 增加 一 个 产品 C， 也 惑 是 说 产品 家 族 
由 原来 的 2 个 增加 到 3 个 ， 看 看 我 们 的 程序 有 多 大 改动 吧 ! 抽象 类 





AbstractCreator 要 增加 一 个 方法 createProductCO， 然 后 两 个 实现 类 都 要 
修改 ， 想 想 看 ， 这 严重 违反 了 开 闭 原则 ， 而 且 我 们 一 直 说 明 抽 象 类 和 接 
口 是 一 个 契约 。 改 变 契 约 ， 所 有 与 契约 有 关系 的 代码 都 要 修改 ， 那 么 这 
段 代 码 叫 什么 ? 叫 “ 有 毒 代码 ”， 只 要 与 这 段 代 码 有 关系 ， 就 可 能 产 
生 侵害 的 危险 ! 








9.3.3 抽象 工厂 模式 的 使 用 场景 





抽象 工厂 模式 的 使 用 场景 定义 非常 简单 :一 个 对 象 族 (或 是 一 组 没 
有 任何 关系 的 对 象 ) 都 有 相同 的 约束 ， 则 可 以 使 用 抽象 工 三 模式。 什么 
意思 呢 ? 例如 一 个 文本 编辑 器 和 一 个 图 片 处 理 器 ， 都 是 软件 实体 ， 但 
是 nix 下 的 文本 编辑 器 和 Windows 下 的 文本 编辑 器 虽然 功能 和 界面 都 相 
同 ， 但 是 代码 实现 是 不 同 的 ， 图 片 处 理 圳 也 有 类 似 情 况 。 也 就 是 具有 了 
共同 的 约束 条 件 ; 操作 系统 类 型 。 于 是 我 们 可 以 使 用 抽象 工厂 模式 ， 产 
生 不 同 操作 系统 下 的 编辑 器 和 疼 片 处 理 器 。 





9.3.4 抽象 工厂 模式 的 注意 事项 


在 抽象 工厂 模式 的 缺点 中 ， 我 们 提 到 抽象 工厂 模式 的 产品 族 扩 展 比 
较 困 难 ， 但 是 一 定 要 清楚 ， 是 产品 族 扩展 困难 ， 而 不 是 产品 等 级 。 在 该 
模式 下 ， 产 品 等 级 是 非常 容易 扩展 的 ， 增 加 一 个 产品 等 级 ， 只 要 增加 一 
个 工 广 类 负责 新 增加 出 来 的 产品 生产 任务 即 可 。 也 就 是 说 横向 扩展 容 

















易 ， 纵 问 扩 展 困 难 。 以 人 类 为 例子 ， 产 品 等 级 中 只 有 男 、 女 两 个 性 别 ， 
现实 世界 还 有 一 种 性 别 : 双 性 人 ， 既 是 男人 也 是 女人 《俗语 就 是 阴阳 

人 ) ， 那 我 们 要 扩展 这 个 产品 等 级 也 是 非常 容易 的 ， 增 加 三 个 产品 类 ， 
分 别 对 应 不 同 的 肤色 ， 然 后 再 创建 一 个 工 三 类， 专门 负责 不 同 肤色 人 的 
双 性 人 的 创建 任务 ， 完 全 通过 扩展 来 实现 需求 的 变更 ， 从 这 一 点 上 看 ， 
抽象 工厂 模式 是 符合 开 闭 原则 的 。 





9.4 最 佳 实践 


一 个 模式 在 什么 情况 下 才能 够 使 用 ， 是 很 多 读者 比较 困惑 的 地 方 。 
抽象 工厂 模式 是 一 个 简单 的 模式 ， 使 用 的 场景 非常 多 ， 大 家 在 软件 产品 
开发 过 程 中 ， 涉 及 不 同 操作 系统 的 时 候 ， 都 可 以 考虑 使 用 抽象 工厂 模 
式 ， 例 如 一 个 应 用 ， 需 要 在 三 个 不 同 平台 (Windows、Linux、 

Android (Google 发 布 的 智能 终端 操作 系统 ) ) 上 运行 ， 你 会 怎么 设 
计 ? 分 别 设计 三 套 不 同 的 应 用 ? 非 也 ， 通 过 抽象 工 三 模式 屏蔽 抒 操 作 系 
统 对 应 用 的 影响 。 三 个 不 同 操作 系统 上 的 软件 功能 、 应 用 逻辑 、UI 都 应 
该 是 非常 类 似 的 ， 唯 一 不 同 的 是 调用 不 同 的 工厂 方法 ， 由 不 同 的 产品 类 
去 处 理 与 操作 系统 交互 的 信息 。 


第 10 章 ”模板 方法 模式 


10.1 辉煌 工程 一 一 制造 悍马 


周三 ，9:00， 我 刚刚 坐 到 位 置 上 ， 打 开 电 脑 准备 开始 干 活 。 


“小 三 ， 小 三 ， 叫 一 下 其 他 同事 ， 到 会 议 室 开会 >， 老 大 跑 过 来 吼 ， 
种 者 坏 笑 。 还 没 等 大 家 坐 稳 ， 老 大 束 开 讲 了: 


“告诉 大 家 一 个 好 消息 ， 昨 天 终于 把 xx 模型 公司 的 口子 打开 了 ， 要 
我 们 做 悍马 模型 ， 虽 然 是 第 一 个 车 辆 模型 ， 但 是 我 们 有 人 能力 、 有 信心 做 
好 ， 我 们 一 定 要 .…….”( 中 间 省 略 20 分 钟 的 讲话 ， 如 果 你 听 过 领导 人 的 


讲话 ， 这 个 你 应 该 能 够 续 上 ) 


动员 工作 做 完了 ， 那 就 开始 压 任务 了 。“ 这 次 时 间 是 非常 紧张 的 ， 
只 有 一 个 星期 的 时 间 ， 小 三 ， 你 负责 在 一 个 星期 的 时 间 把 这 批 10 万 车 模 
( 注 ; 车 模 是 车 辆 模型 的 意思 ， 不 是 香 车 美女 那个 车 模 ) 建设 完 


“一 个 星期 ? 这 个 .…… 是 真 做 不 完 ， 要 做 分 析 ， 做 模板 ， 做 测试 ， 
还 要 考虑 扩展 性 、 稳 定性 、 健 壮 性 等 ， 时 间 实 在 是 太 少 了 。” 还 没 等 老 
大 说 完 ， 我 就 急 了 ， 再 不 急 我 的 小 命 就 折 在 上 面 了 ! 


“ 那 这 样 ， 只 做 最 基本 的 实现 ， 不 考虑 太 多 的 问题 ， 上 怎么 样 ? ”老大 
又 把 我 弹 回去 了 。 


“只 作 基 本 实现 ? 那 ..…....” 


唉 ， 领 导 已 经 布置 任务 了 ， 那 就 开始 拼命 地 做 吧 。 然 后 就 开始 准备 
动手 做 ， 在 做 之 前 先 介绍 一 下 我 们 公司 的 背景 ， 我 们 公司 是 做 模型 生产 
的 ， 做 过 桥 染 模型、 建筑 模型 、 机 械 模型 ， 甚 至 是 一 些 政 府 、 军 事 的 机 
密 模型 ， 这 个 不 能 细 说 ， 绝 密 。 公 司 的 主要 业务 就 是 把 实物 按照 一 定 的 
比例 缩小 或 放大 ， 用 于 试验 、 分 析 、 量 化 或 者 是 销售 ， 等 等 ， 上 面 提 到 
的 xx 模型 公司 是 专门 销售 车 辆 模型 的 公司 ， 目 己 没 有 生产 企业 ， 全 部 是 
代 工 。 我 们 公司 是 第 一 次 从 xx 模型 公司 接 单 ， 那 我 怎么 着 也 要 把 活 干 
好 ， 可 时 间 有 限 ， 任 务 量 又 巨大 ， 怎 么 办 ? 























既然 领导 都 说 了 ， 不 考虑 扩展 性 ， 那 好 办 ， 先 按照 最 一 般 的 经 验 设 
计 类 图 ， 如 图 10-1 所 示 。 













HummerModel 定义 一 个 抽象 类 ， 悍 马车 模型 人 
了 start() 启 动车 辆 
tvoid stari) stop0 停 止 车 辆 
t+void stop() alarmg0 喇 叭 鸣叫 
+void alarm() 。 引擎 发 出 篆 鸣 声 
+void engineBoom!() Soon) oe ne 


t+void run() run() 汽车 跑 起 来 





HummerH1Model HummerH2Model 





图 10-1 悍马 车 模型 最 一 般 的 类 图 


非常 简单 的 实现 ， 悍 马车 有 两 个 型 号 ，H1 和 H2。 按 照 需求 ， 只 需 
要 悍马 模型 ， 那 好 我 就 给 你 悍马 模型 ， 先 写 个 抽象 类 ， 然 后 两 个 不 同型 
号 的 模型 实现 类 ， 通 过 简单 的 继承 就 可 以 实现 业务 要 求 。 我 们 先 从 抽象 
类 开始 编写 ， 抽 象 悍 马 模型 如 代码 清单 10-1 所 示 。 


代码 清单 10-1 抽象 悍马 模型 


public abstract class HummerModel { 
/A 
* 首先 ， 这 个 模型 要 能 够 被 发 动 起 来 ， 别 管 是 手 摇 发 动 ， 还 是 电力 发 动 ， 反 正 
* 是 要 能 够 发 动 起 来 ， 那 这 个 实现 要 在 实现 类 里 了 
4 
public abstract void start(); 
// 能 发 动 ， 还 要 能 停 下 来 ， 那 才 是 真 本 事 


public abstract void stop(); 




















// 喇 叭 会 出 声音 ， 是 滴 滴 叫 ， 还 是 哗 哗 叫 

public abstract void alarm( ) 

/V/ 引 擎 会 爱 隆 隆 地 响 ， 不 响 那 是 假 的 

public abstract void engineBoom( ) ; 

// 那 模型 应 该 会 跑 吧 ， 别 管 是 人 推 的 ， 还 是 电力 驱动 的 ， 总 之 要 会 跑 
public abstract void run( ) ; 








在 抽象 关中， 我 们 定义 了 悍马 模型 都 必须 具有 的 特质 能够 发 动 、 
停止 ， 喇 叭 会 啊 ， 引 擎 可 以 和 受 哆 ， 而 且 还 可 以 停止 。 但 是 每 个 型 志 的 悍 
马 实现 是 不 同 的 ，H1 型 号 的 悍马 如 代码 清单 10-2 所 示 。 








代码 清单 10-2 H1 型 号 悍马 模型 


public class HummerHiModel extends HummerModel { 
//H1i 型 号 的 悍马 车 鸣 笛 
public void alarm() { 
System.out,println(" 悍 马 H1 鸣 笛 ,. .")， 


} 
// 引 擎 到 鸣 声 
public void engineBoom() { 
System.out.printLn(" 悍 马 H1 引 警 声音 是 这 样 的 . .."); 


} 

// 汽 车 发 动 

public void start() { 
System.out,printJIn(" 悍 马 H1 发 动 , ,,"); 

















// 停 车 
public void stop() { 
System.out.,println(" 悍 马 H1 停 车 ,.."); 


} 

// 开 动 起 来 

public void run(){ 
// 先 发 动 汽车 
this.start(); 
// 引 擎 开始 受 鸣 
this.engineBoom( ) ; 
// 然 后 就 开始 跑 了 ， 跑 的 过 程 中 遇 到 一 条 狗 挡 路 ， 就 按 喇 叭 
this.alarm( ); 
// 到 达 目 的 地 就 停车 
this.stop(); 








-一 


大 家 注意 看 run(0) 方 法 ， 这 是 一 个 汇总 的 方法 ， 一 个 模型 生产 成 功 
了 ， 总 要 拿 给 客户 检测 吧 ， 怎 么 检测 ?“ 是 又 子 是 马 ， 拉 出 去 溜溜 "， 这 
就 是 一 种 检验 方法 ， 让 它 跑 起 来 ! 通过 run() 这 样 的 方法 ， 把 模型 的 所 有 
功能 都 测试 到 了 。 


H2 型 号 悍马 如 代码 清单 10-3 所 示 。 


代码 清单 10-3 H2 型 号 悍马 模型 


public class HummerH2Model extends HummerModel { 
//H2 型 号 的 悍马 车 鸣 笛 
public void alarm() { 
System.out,println(" 悍 马 H2 鸣 笛 ,..")， 


} 

// 引 擎 禾 鸣 声 

public void engineBoom() { 
System.out.printLn(" 悍 马 H2 引 警 声音 是 这 样 在 ..."); 


} 

// 汽 车 发 动 

public void start() { 
System.out,printJIn(" 悍 马 H2 发 动 , ,,"); 

















} 

// 停 车 

public void stop() { 
System,out,.printlLn(" 悍 马 H2 停 车 .. ."); 


} 

// 开 动 起 来 

public void run(){ 
// 先 发 动 汽车 
this.start(); 
// 引 擎 开始 笑 鸣 
this.engineBoom( ) ; 
// 然 后 就 开始 跑 了 ， 跑 的 过 程 中 遇 到 一 条 狗 挡 路 ， 就 按 喇 叭 
this.alarm( ) ; 
// 到 达 目 的 地 就 停车 
this.stop(); 








好 了 ， 程 序 编写 到 这 里 ， 已 经 发 现 问题 了 ， 两 个 实现 类 的 run(0) 方 法 
都 是 完全 相同 的 ， 那 这 个 run0) 方 法 的 实现 应 该 出 现在 抽象 类 ， 不 应 该 在 
实现 类 上 ， 抽 象 是 所 有 子 类 的 共性 封装 。 








注意 ”在 软件 开发 过 程 中 ， 如 果 相 同 的 一 段 代 码 复制 过 两 次 ， 殊 
需要 对 设计 产生 怀疑 ， 染 构 师 要 明确 地 说 明 为 什么 相同 的 迎 辑 要 出 现 两 





好 ， 问 题 及 现 了 ， 我 们 就 需要 马上 更 改 ， 修 改 后 的 类 图 如 图 10-2 所 


Client 









定义 一 个 抽象 类 ， 悍马 车 模型 ~ 
start() 启 动车 辆 
stop() 停 止 车 辆 


EO 
FF 
HummerModel 


A 
+Void start() 
+Void stop!() 
+vVoid alarm() 
+VoOid engineBoom!() 


Vold run 


alarm0 喇 叭 史 叫 
engineBoom(0 引 警 发 出 秀 呜 声 


run() 汽 车 跑 起 来 












HummerH]lModel HummerH2Model 





图 10-2 修改 后 的 悍马 车 模 类 图 


注意 ， 抽 象 类 HummerModel 中 的 run0 方 法 ， 由 抽象 方法 变更 为 实现 
方法 ， 其 源 代码 如 代码 清单 10-4 所 示 。 


代码 清单 10-4 修改 后 的 抽象 悍马 模型 


public abstract class HummerModel { 
/* 


* 首先 ， 这 个 模型 要 能 发 动 起 来 ， 别 管 是 手 摇 发 动 ， 还 是 电力 发 动 ， 反 正 
* 是 要 能 够 发 动 起 来 ， 那 这 个 实现 要 在 实现 类 里 了 
4 
public abstract void start(); 
// 能 发 动 ， 还 要 能 停 下 来 ， 那 才 是 真 本 寻 
public abstract void stop(); 
// 喇 叭 会 出 声音 ， 是 滴 滴 叫 ， 还 是 哗 哗 叫 
public abstract void alarm( ) ， 
/V/ 引 擎 会 爱 隆 隆 地 响 ， 不 响 那 是 假 的 
public abstract void engineBoom( ) ; 
// 那 模型 应 该 会 跪 吧 ， 别 管 是 人 推 的 ， 还 是 电力 驱动 ， 总 之 要 会 跑 
public void run(){ 
// 先 发 动 汽车 
this.start(); 
// 引 擎 开始 友 鸣 
this.engineBoom( ) ; 
// 然 后 就 开始 跑 了 ， 跑 的 过 程 中 遇 到 一 条 狗 挡 路 ， 就 按 喇 只 
this.alarm( ); 
// 到 达 目 的 地 就 停车 
this.stop(); 


























mt 

















在 抽象 的 悍马 模型 上 已 经 定义 了 run() 方 法 的 执行 规则 ， 先 启动 ， 然 
后 引擎 立刻 爱 鸣 ， 中 间 还 要 按 一 下 喇叭 ， 制 造 点 噪声 〈 要 不 束 不 是 名 车 
了 ) 。 然 后 停车 ， 它 的 两 个 具体 实现 类 就 不 需要 实现 run(0) 方 法 了 了， 只 要 
把 代码 清单 10-2、 代 码 清单 10-3 上 的 run0) 方 法 删除 即 可 ， 不 再 歼 述 代 





个 。 


场景 类 实现 的 任务 就 是 把 生产 出 的 模型 展现 给 客户 ， 其 源 代码 如 代 
码 清 单 10-5 所 示 。 


代码 清单 10-5 场景 类 


public class Client { 
public static void main(String[|] args) { 
//XX 公 司 要 Hi 型 号 的 悍马 
HummerModel hi = new HummerH1iModel( ) ， 
//H1 模 型 演示 
hi.run( ); 














CE 


运行 结果 如 下 所 示 。 


悍马 H1 发 动 .. 


悍马 H1 引 擎 声音 是 这 样 的 ... 








悍马 HI 鸣 笛 .… 











悍马 HI1 停 车 … 


目前 客户 只 要 看 HI 型 号 的 悍马 车 ， 没 问题 ， 生 产 出 来 ， 同 时 可 以 
运行 起 来 给 他 看 看 。 非 党 简单， 那 如 果 我 告诉 你 这 就 是 模板 方法 模式 你 
会 不 会 很 不 收 呢 ? 残 这 模式 ， 太 简单 了 ， 我 一 直 在 使 用 呀 ! 是 的 ， 你 经 
常 在 使 用 ， 但 你 不 知道 这 是 模板 方法 模式 ， 那 些 所 谓 的 高 手 就 可 以 很 牛 
地 说 :“ 用 模板 方法 模式 就 可 以 实现 "， 你 还 要 很 肥 拜 地 看 者 ， 哇 ， 牛 
人 ， 模 板 方 法 模式 是 什么 蚜 ? 这 就 是 模板 方法 模式 。 











10.2 模板 方法 模式 的 定义 


模板 方法 模式 (“Template Method Pattern) 是 如 此 简单 ， 以 致 让 你 


感 党 你 已 经 能 够 掌握 其 精 舌 了。 其 定义 如 下 : 


Define the skeleton of an algorithm in an operation,deferring some steps 
to subclasses.Template Method lets subclasses redefine certain steps of an 
algorithm without changing the algorithm's structure. (定义 一 个 操作 中 的 
算法 的 框架 ， 而 将 一 些 步骤 延迟 到 子 类 中 。 使 得 子 类 可 以 不 改变 一 个 算 
法 的 结构 即 可 重 定义 该 算法 的 茶 些 特定 步骤 。) 





模板 方法 模式 的 通用 类 图 如 图 10-3 所 示 。 


AbstractClass 


| 
Hvoid doAnything() 
#void doSomething!() 
+void template Method() 


ConcreteClass2 





图 10-3 修改 后 的 悍马 车 模 类 图 





模板 方法 模式 确实 非常 简单 ， 仅 仅 使 用 了 Java 的 继承 机 制 ， 但 它 是 
一 个 应 用 非常 广泛 的 模式 。 其 中 ，AbstractClass 叫 做 抽象 模板 ， 它 的 方 
法 分 为 两 类 : 


e 基本 方法 


基本 方法 也 叫做 基本 操作 ， 是 由 子 类 实现 的 方法 ， 并 且 在 模板 方法 
被 调用 。 


e 模板 方法 


可 以 有 一 个 或 几 个 ， 一 般 是 一 个 具体 方法 ， 也 就 是 一 个 框架 ， 实 现 
对 基本 方法 的 调度 ， 完 成 固定 的 逻辑 。 





注意 “为 了 防止 恶意 的 操作 ， 一 般 模 板 方法 都 加 上 final 关 键 字 ， 不 
允许 被 履 写 。 


在 类 图 中 还 有 一 个 角色 : 具体 模板 。ConcreteClass1 和 
ConcreteClass2 属 于 具体 模板 ， 实 现 父 类 所 定义 的 一 个 或 多 个 抽象 方 
法 ， 也 就 是 父 类 定义 的 基本 方法 在 子 类 中 得 以 实现 。 





我 们 来 看 其 通用 代码 ，AbstractClass 如 代码 清单 10-6 所 示 。 


代码 清单 10-6 抽象 模板 类 


public abstract class AbstractClass { 
// 基 本 方法 
protecte 


d abstract void doSomething(); 
// 基 本 方法 
d 








protecte 
// 模 板 方 法 
public void templateMethod(){ 
冰雪 
* 调用 基本 方法 ， 完 成 相关 的 逻辑 
*/ 
this.doAnything( ); 
this.doSomething(); 


abstract void doAnything(); 


























具体 模板 如 代码 清单 10-7 所 示 。 


代码 清单 10-7 具体 模板 类 


public class ConcreteClass1 extends AbstractClass { 
// 实 现 基 本 方法 
protected void doAnything() { 

// 业 务 逻 辑 处 理 






































protected void doSomething() { 
// 业 务 逻 辑 处 理 
} 


public class ConcreteClass2 extends AbstractClass { 
// 实 现 基本 方法 
protected void doAnything() { 













































































// 业 务 逻 辑 处 理 

} 

protected void doSomething() { 
// 业 务 逻 辑 处 理 

} 


场景 类 如 代码 清单 10-8 所 示 。 


代码 清单 10-8 场景 类 


public class Client { 
public static void main(String[] args) { 
AbstractClass class1 = new ConcreteClass1(); 
AbstractClass class2 = new ConcreteClass2(); 
// 调 用 模板 方法 
class1.templateMethod( ); 
class2.templateMethod( ); 








注意 “抽象 模板 中 的 基本 方法 尽量 设计 为 protected 类 型 ， 符 合 迪 米 
特 法 则 ， 不 需要 骏 露 的 属性 或 方法 尽量 不 要 设置 为 protected 类 型 。 实 现 
类 奋 非 必要 ， 尽 量 不 要 扩大 父 类 中 的 访问 权限 。 














10.3 模板 方法 模式 的 应 用 





10.3.1 模板 方法 模式 的 优点 


e 封装 不 变 部 分 ， 扩 展 可 变 部 分 





把 认为 是 不 变 部 分 的 算法 封闭 到 父 类 实现 ， 而 可 变 部 分 的 则 可 以 通 
过 继承 来 继续 扩展 。 在 悍马 模型 例子 中 ， 是 不 是 就 非 第 容易 扩展 ?例如 
增加 一 个 H3 型 号 的 悍马 模型 ， 很 容易 呀 ， 增 加 一 个 子 类 ， 实 现 父 类 的 
基本 方法 就 可 以 了 。 











e 提取 公共 部 分 代码 ， 便 于 维护 


我 们 例子 中 刚刚 走 过 的 弯路 就 是 最 好 的 证 明 ， 如 果 我 们 不 抽取 到 父 
类 中 ， 任 由 这 种 散乱 的 代码 发 生 ， 想 想 后 果 是 什么 样子 ? 维护 人 员 为 了 
修正 一 个 缺陷 ， 需 要 到 处 得 找 类 似 的 代码 ! 


e 行为 由 父 类 控制 ， 子 类 实现 





基本 方法 是 由 子 类 实现 的 ， 因 此 子 类 可 以 通过 扩展 的 方式 增加 相应 
的 功能 ， 符 合 开 财 原则 。 





10.3.2 模板 方法 模式 的 缺点 


按照 我 们 的 设计 习惯 ， 抽 象 类 负责 声明 最 抽象 、 最 一 般 的 事物 属性 
和 方法 ， 实 现 类 完成 具体 的 事物 属性 和 方法 。 但 是 模板 方法 模式 却 颠 倒 
了 ， 抽 象 类 定义 了 部 分 抽象 方法 ， 由 子 类 实现 ， 子 类 执行 的 结果 影响 了 
父 类 的 结果 ， 也 就 是 子 类 对 父 类 产生 了 影响 ， 这 在 复 洒 的 项 目 中 ， 会 带 
来 代码 阅读 的 难度 ， 而 且 也 会 让 新 手 产生 不 适 感 。 














10.3.3 模板 方法 模式 的 使 用 场景 


e 多 个 子 类 有 公有 的 方法 ， 并 且 逻 辑 基 本 相同 时 。 


e 重要 、 复 杂 的 算法 ， 可 以 把 核心 算法 设计 为 模板 方法 ， 周 边 的 相 
关 细 市 功能 则 由 各 个 子 类 实现 。 





e 重 构 时 ， 模 板 方 法 模式 是 一 个 经 常 使 用 的 模式 ， 把 相同 的 代码 抽 
取 到 父 类 中 ， 然 后 通过 钧 子 函 数 〈 见 “模板 方法 模式 的 扩展 ?) 约束 其 行 
为 。 


10.4 模板 方法 模式 的 扩展 











到 目前 为 止 ， 这 两 个 模型 都 稳定 地 运行 ， 突 然 有 一 天 ， 老 大 急匆匆 
地 找到 了 我 : 


“看 你 怎么 设计 的 ， 车 子 一 局 动 ， 喇 叭 就 狂 啊 ， 吵 死人 了 ! 客户 提 
出 H1 型 号 的 悍马 喇叭 想 让 它 啊 就 啊 ，H2 型 号 的 喇叭 不 要 有 声音 ， 赶 快 
修改 一 下 。” 


自己 车 的 祸 ， 就 要 想 办 法 解决 它 ， 稍 稍 思考 一 下 ， 解 决 办 法 有 了 ， 
先 画 出 类 图 ， 如 图 10-4 所 示 。 


HummerModel 


| 
#void start() 
#void stopl) 
#yoid alarm!() 
#void engine Boom!() 
+vold run() 
#boolean isAlarm() 


HummerH2Model 





+Vold setAlarm(boolean isAlarm) 


图 10-4 扩展 悍马 车 模 类 图 


类 图 改动 似乎 很 小 ， 在 抽象 类 HummerModel 中 增加 了 一 个 实现 方法 
isAlarm， 确 定 各 个 型 豆 的 悍马 是 否 需 要 声音 ， 由 各 个 实现 类 获 写 该 方 
法 ， 同 时 其 他 的 基本 方法 由 于 不 需要 对 外 提供 访问 ， 因 此 也 设计 为 
protected 类 型 。 其 源 代 码 如 代码 清单 10-9 所 示 。 








代码 清单 10-9 扩展 后 的 抽象 模板 类 


public abstract class HummerModel { 
/* 

















* 首先 ， 这 个 模型 要 能 够 梓 发 动 起 来 ， 别 管 是 手 摇 发 动 ， 还 是 电力 改动， 反正 
* 是 要 能 够 发 动 起 来 ， 那 这 个 实现 要 在 实现 类 里 了 
protected abstract void start(); 
// 能 发 动 ， 还 要 能 停 下 来 ， 那 才 是 真 本 事 
protected abstract void stop(); 
// 喇 叭 会 出 声音 ， 是 滴 滴 叫 ， 还 是 哗 哗 叫 
protected abstract void alarm( ) ; 
/V/ 引 擎 会 受 隆 隆 的 响 ， 不 响 那 是 假 的 
protected abstract void engineBoom( ) ; 
// 那 模型 应 该 会 跪 吧 ， 别 管 是 人 推 的 ， 还 是 电力 驱动 ， 总 之 要 会 跑 
final public void run() { 
// 先 发 动 汽车 
this.start(); 
// 引 擎 开始 缀 鸣 
this.engineBoom( ) ; 
// 要 让 和 它 叫 的 就 是 就 叫 ， 喇 嘛 不 想 让 它 响 就 不 响 
if(this.isAlarm()){ 
this.alarm( ); 


} 
// 到 达 目 的 地 就 停车 
this.stop(); 


} 

// 钓 子 方法 ， 默 认 喇叭 是 会 啊 的 
protected boolean isAlarm(){ 
return true,; 

} 






































在 抽象 类 中 ，isAlarm 是 一 个 实现 方法 。 其 作用 是 模板 方法 根据 其 
返回 值 决定 是 否 要 响 喇 从， 子 类 可 以 履 写 该 返回 值 ， 由 于 H1 型 写 的 喇 
只 是 想 让 它 啊 就 响 ， 不 想 让 它 响 就 不 响 ， 由 人 控制 ， 其 源 代码 如 代码 清 
单 10-10 所 示 。 


代码 清单 10-10 扩展 后 的 Hl 悍 马 


public class HummerHiModel extends HummerModel { 
private boolean alarmFlag = true; // 要 响 喇叭 
protected void alarm() { 
System.out.printLn(" 悍 马 H1 鸣 笛 ..."); 
} 








protected void engineBoom() 
System.out.printLn(" 悍 马 H1 引 警 声音 是 这 样 的 . .."); 








protected void start() { 
System.out.printlin(" 悍 马 H1 发 动 ..."); 





protected void stop() { 
System.out.,printlin(" 悍 马 H1 停 车 ,.."); 








protected boolean isAlarm() { 
return this.alarmFlag; 


} 

// 要 不 要 响 喇 叭 ， 是 由 客户 来 决定 的 

public void setAlarm(boolean isAlarm)t{ 
this.alarmFlag = isAlarm; 

} 





























只 要 调用 H1 型 号 的 悍 号 ， 默 认 是 有 喇叭 啊 的 ， 当 然 你 可 以 不 让 喇 
以 啊 ， 通 过 isAlarm(false) 惑 可 以 实现 。H2 型 扎 的 悍马 是 没有 喇叭 声 啊 
的 ， 其 源 代 码 如 代码 清单 10-11 所 示 。 








代码 清单 10-11 扩展 后 的 H2 悍 马 


public class HummerH2Model extends HummerModel { 
protected void alarm() { 
System.out.printLn(" 悍 马 H2 鸣 笛 ..."); 





protected void engineBoom( ) { 
System.out.printLn(" 悍 马 H2 引 警 声音 是 这 样 的 . .."); 








protected void Start() { 
System.out,printJln(" 悍 马 H2 发 动 ,,,"); 








protected void stop() { 
System.out.,println(" 悍 马 H2 停 车 ,.."); 


} 

// 默 认 没有 喇叭 的 

protected boolean isAlarm() { 
return false; 

2. 














H2 型 号 的 悍马 设置 isAlarm0 的 返回 值 为 false， 也 就 是 关闭 了 喇叭 功 
能 。 场 景 类 代码 如 代码 清单 10-12 所 示 。 


代码 清单 10-12 扩展 后 的 场景 类 


public class Client { 
public static void main(String[] args) throws IOException { 
System,out,println("------- H1 型 号 悍马 -------- Ds, 
System.out.println("H1i 型 号 的 悍马 是 否 需 要 喇叭 声响?0- 不 需要 
String type=(new BufferedReader (new InputStreamReade 
HummerHiModel hi = new HummerH1iModel(); 
if(type.equals("0"))t{ 
hi.setAlarm(false); 


























hi.run( ); 

System,out.println("\n------- H2 型 号 悍马 -------- "); 
HummerH2Model h2 = new HummerH2Model(); 

h2.run( ); 














运行 是 需要 交互 的 ， 首 先 ， 要 求 输入 H1 型 写 的 悍马 是 否 有 声 首 ， 

















se H1 型 号 悍马 -------- 


























H1 型 号 的 悍马 是 否 需要 喇叭 声 啊 ? 0- 不 需要 1- 需 要 








输入 “0” 后 的 运行 结果 如 下 所 示 : 


























半 
睛 

浊 
至 
醒 
由 





个 需要 喇叭 声 啊 ? 0- 不 需要 1- 需 要 











悍马 HI 发 动 .… 























悍马 HI 引擎 声音 是 这 样 的 .… 
悍马 HI 停车 … 

------- H2 型 号 悍马 -------- 
悍马 H2 发 动 .… 


悍马 H2 引 警 声音 是 这 样 的 … 














悍马 H2 停 车 … 


输入 “1” 后 的 运行 结果 如 下 所 示 : 





























H1 型 号 的 悍马 是 否 需要 喇叭 声 啊 ? 0- 不 需要 1- 需要 








悍马 HI 发动.… 


悍马 H1 引 擎 声音 是 这 样 的 ... 








悍马 H1 鸣 笛 .… 











悍马 H1 停 车 .… 





------- H2 型 号 悍马 -------- 





悍马 H2 发 动 .… 


悍马 H2 引 警 声音 是 这 样 的 … 














悍马 H2 停 车 .. 





看 到 没 ，H1 型 亏 的 悍马 是 由 客户 自己 控制 是 否 要 啊 喇 叭 ， 也 就 是 
说 外 界 条 件 改变 ， 影 响 到 模板 方法 的 执行 。 在 我 们 的 抽象 类 中 isAlarm 
的 返回 值 融 是 影响 了 模板 方法 的 执行 结果 ， 该 方法 就 叫做 钩子 方法 








(Hook Method) 。 有 了 钩子 方法 模板 方法 模式 才 算 完美 ， 大 家 可 以 想 
想 ， 由 子 类 的 一 个 方法 返回 值 决 定 公 共 部 分 的 执行 结果 ， 是 不 是 很 有 了 吸 
引力 呀 ! 











模板 方法 模式 就 是 在 模板 方法 中 按照 一 定 的 规则 和 顺序 调用 基本 方 
法 ， 具 体 到 前 面 那个 例子 ， 就 是 run() 方 法 按照 规定 的 顺序 〈 先 调用 
start()， 然 后 再 调用 engineBoom()， 再 调用 alarm()， 最 后 调用 stop()) 调 
用 本 类 的 其 他 方法 ， 并 且 由 isAlarm() 方 法 的 返回 值 确定 run0 中 的 执行 顺 


10.5 最 佳 实践 








初级 程序 员 在 写 程 友 的 时 候 经 常会 问 高 手 “ 父 类 怎么 调用 子 类 的 方 
法 ”。 这 个 问题 很 有 普遍 性 ， 反 正 我 是 被 问 过 好 几 回 ， 那 么 父 类 是 否 可 
以 调用 子 类 的 方法 呢 ? 我 的 回答 是 能 ， 但 强烈 地 、 极 度 地 不 建议 这 人 么 
做 ， 那 该 怎么 做 呢 ? 





e 把 子 类 传递 到 父 类 的 有 参 构造 中 ， 然 后 调用 。 
e 使 用 反射 的 方式 调用 ， 你 使 用 了 反射 还 有 谁 不 能 调用 的 ? ! 
e 父 关 调用 子 类 的 静态 方法 。 


这 三 种 都 是 父 类 直接 调用 子 类 的 方法 ， 好 用 不 ?好 用 ! 解决 问题 了 
吗 ? 解决 了 ! 项 目 中 允许 使 用 不 ? 不 允许 ! 我 就 一 直 没 有 搞 懂 为 什么 要 
用 父 类 调用 子 类 的 方法 。 如 果 一 定 要 调用 子 类 ， 那 为 什么 要 继承 它 呢 ? 
搞 不 懂 。 其 实 这 个 问题 可 以 换个 角度 去 理解 ， 父 类 建立 框架 ， 子 类 在 重 
写 了 父 类 部 分 的 方法 后 ， 再 调用 从 父 类 继承 的 方法 ， 产 生 不 同 的 结果 
(而 这 正 古 模板 方法 模式 ) 。 这 是 不 是 也 可 以 理解 为 父 类 调用 了 子 类 的 
方法 呢 ? 你 修改 了 子 类 ， 影 响 了 父 类 行为 的 结果 ， 曲 线 救国 的 方式 实现 
了 父 类 依赖 子 炎 的 场景 ， 模 板 方法 模式 就 是 这 种 效果 。 


模板 方法 在 一 些 开 源 框架 中 应 用 非 肖 多 ， 它 提供 了 一 个 抽象 类 ， 然 


后 开源 框架 写 了 一 堆 子 类 。 在 《xxx In Action》 中 就 说 明了 ， 如 果 你 需 
要 扩展 功能 ， 可 以 继承 这 个 抽象 类 ， 然 后 禾 写 protected 方 法 ， 再 然后 就 
征调 用 一 个 类 似 execute 方 法 ， 就 完成 你 的 扩展 开 及 ， 非 常 容 易 扩 展 的 一 
种 模式 。 





第 11 章 ”建造 者 模式 


11.1 变化 是 永恒 的 


又 是 一 个 周三 ， 快 要 下 班 了 ， 老 大 突然 拉 住 我 ， 喜 洲 洲 地 告诉 
我 : “xx 公司 很 满意 我 们 做 的 模型 ， 又 签订 了 一 个 合同 ， 把 奔驰 、 宝 马 
的 车 辆 模型 都 交 给 我 们 公司 制作 了 ， 不 过 这 次 又 额外 增加 了 一 个 新 需 
求 : 汽车 的 启动 、 停 止 、 喇 叭 声音 、 引 擎 声音 都 由 客户 上 自己 控制 ， 他 想 
什么 顺序 就 什么 顺序 ， 这 个 没 问 题 吧 ? ” 











那 任务 又 是 一 个 时 间 紧 、 工 程 量 大 的 项 目 ， 为 什么 是 “又 ? 呢 ? 因为 
基本 上 每 个 项 目 都 是 如 此 ， 我 该 怎么 来 完成 这 个 任务 呢 ? 











首先 ， 我 们 分 析 一 下 需求 ， 奔 驰 、 宝 马 都 是 一 个 产品 ， 它 们 有 共有 
的 属性 ，xx 公 司 关 心 的 是 单个 模型 的 运行 过 程 : 奔驰 模型 A 是 先 有 引擎 
声音 ， 然 后 再 啊 喇 只 ;奔驰 模型 B 是 先 月 动 起 来 ， 然 后 再 有 引擎 声音 ， 
这 才 是 xx 公司 要 关心 的 。 那 到 我 们 老大 这 边 呢 ， 惑 是 满足 人 家 的 要 求 ， 
要 什么 顺序 就 立马 能 产生 什么 顺序 的 模型 出 来 。 我 就 负责 把 老大 的 要 求 
实现 出 来 ， 而 且 还 要 是 批量 的 ， 也 就 是 说 xx 公司 下 单 订 购 宝马 A 和 车模， 
我 们 老大 马上 惑 找 我 “生产 一 个 这 样 的 车 模 ， 局 动 完 毕 后 ， 喇 叭 啊 一 
下 ”， 然 后 我 们 就 准备 开始 批量 生产 这 些 模型 。 由 我 生产 出 N 多 个 奔驰 和 














宝马 车 辆 模型 ， 这 些 车 辆 模型 都 有 run() 方 法 ， 但 是 具体 到 每 一 个 模型 的 
run0) 方 法 中 间 的 执行 任务 的 顺序 是 不 同 的 ， 老 大 说 要 啥 顺 序 ， 我 融 给 哈 
顺序 ， 最 终 客 户 买 走 后 只 能 是 既定 的 模型 。 好 ， 需 求 还 是 比较 复杂 ， 我 
们 先 一 个 一 个 地 解决 ， 先 从 找 一 个 最 简单 的 切入 点 一 一 产品 类 ， 每 个 车 
都 是 一 个 产品 ， 如 图 11-1 所 示 。 


CarModel 


ee 
#yoid start() 
#void stop() 
#yvoid alarm!() 
#yoid engineBoom() 
+vold run() 








+Vold setSequence(ArrayList sequence) 


BenzModel BMWModel 





奔驰 实现 头 宝马 实现 类 





图 11-1 汽车 模型 类 图 


类 图 比较 简单 ， 在 CarModel 中 我 们 定义 了 一 个 setSequence 方 法 ， 车 
辆 模型 的 这 几 个 动作 要 如 何 排 布 ， 是 在 这 个 ArrayList 中 定义 的 。 然 后 





run() 方 法 根据 sequence 定 义 的 顺序 完成 指定 的 顺序 动作 ， 与 第 10 章 介绍 
的 模板 方法 模式 是 不 是 非常 类 似 ? 好， 我 们 先 看 CarModel 源 代码 ， 如 代 
码 清单 11-1 所 示 。 








代码 清单 11-1 车 辆 模型 的 抽象 类 


public abstract class CarModel { 
// 这 个 参数 是 各 个 基本 方法 执行 的 顺序 
private ArrayList<String> sequence = new ArrayList<String>() 
// 模 型 是 启动 开始 跑 了 
protected abstract void start(); 
// 能 发 动 ， 还 要 能 停 下 来 ， 那 才 是 真 本 事 
protected abstract void stop(); 
// 喇 叭 会 出 声音 ， 是 滴 滴 叫 ， 还 是 哗 哗 叫 
protected abstract void alarm( ) ; 
/V/ 引 警 会 惨 隆 隆 地 响 ， 不 响 那 是 假 的 
protected abstract void engineBoom( ) ; 
// 那 模型 应 该 会 跪 吧 ， 别 管 是 人 推 的 ， 还 是 电力 驱动 ， 总 之 要 会 跑 
final public void run() { 
// 循 环 一 边 ， 谁 在 前 ， 就 先 执行 谁 
for(int i=0;i<this.sequence.size();i++){ 
String actionName = this.sequence.get(1i); 
if(actionName.equalsIgnoreCase("start"))t{ 
this.start(); // 启 动 汽车 
}else if(actionName.equalsIgnoreCase("stop" 
this,stop(); // 停 止 汽 车 
}else if(actionName.equalsIgnoreCase("alarm 
this.alarm(); // 喇 只 开始 叫 了 
}else if(actionName.equalsIgnoreCase("engi 
// 如 琳 


this,engineBoom()， ”// 引 人 擎 开始 艇 鸣 



































} 

} 

// 把 传递 过 来 的 值 传递 到 类 内 

final public void setSequence(ArrayList sequence)t{ 
this.sequence = sequence; 

} 


CarModel 的 设计 原理 是 这 样 的 ，setSequence 方 法 是 允许 客户 自己 设 


置 一 个 顺序 ， 是 要 移 司 动 啊 一 下 喇叭 再 跑 起 来 ， 还 是 要 移 啊 一 下 喇叭 再 
局 动 。 对 于 一 个 具体 的 模型 永远 都 固定 的 ， 但 十 对 N 多 个 模型 就 是 动态 
的 了 。 在 子 类 中 实现 父 类 的 基本 方法 ，run() 方 法 读 取 sequence， 然 后 所 
历 sequence 中 的 字符 串 ， 哪 个 字符 串 在 和 完 ， 就 先 执行 哪个 方法 。 





两 个 实现 类 分 别 实现 父 类 的 基本 方法 ， 奔 驰 模 型 如 代码 清单 11-2 所 


代码 清单 11-2 奔驰 模型 代码 


public class BenzModel extends CarModel { 
protected void alarm() { 
System.out.println(" 奔 驰 车 的 喇叭 声音 是 这 个 样子 的 ...")，; 





protected void engineBoom() { 
System.out.println(" 奔 驰 车 的 引擎 是 这 个 声音 的 ...")， 


protected void start() { 
System.out.println(" 奔 驰 车 跑 起 来 是 这 个 样子 的 ...")， 





protected void stop() { 
System.out.println(" 奔 驰 车 应 该 这 样 停车 ...")，; 
} 





宝马 车 模型 如 代码 清单 11-3 所 示 。 


代码 清单 11-3 宝马 模型 代码 


public class BMWModel extends CarModel { 
protected void alarm() { 
System.out.println(" 宝 马车 的 喇叭 声音 是 这 个 样子 的 . .."); 





protected void engineBoom( ) { 
System,out,.printlLn(" 宝 马车 的 引 警 是 这 个 声音 的 ,,..,"); 
} 





protected void start() { 





System,out.,println(" 宝 马车 跑 起 来 是 这 个 样子 的 ,,."); 


protected void stop() { 


} 








System.out.println(" 宝 马车 应 该 这 样 停车 ..."); 


两 个 产品 的 实现 类 都 完成 ， 我 们 来 模拟 一 下 xx 公 司 的 要 求 ， 生 产 一 
个 奔驰 模型 ， 要 求 跑 的 时 候 ， 先 发 动 引擎 ， 然 后 再 挂 挡 启动 ， 然 后 停 下 
来 ， 不 需要 喇叭 。 这 个 需求 很 容易 满足 ， 我 们 增加 一 个 场景 类 实现 该 需 


求 ， 如 代码 清单 11-4 所 示 。 





代码 清单 11-4 奔驰 模型 代码 


public class Client { 
public static void main(String[] args) { 


春 


分 





春 


秀 


-一 


/* 
* 客户 告诉 XX 公司 ， 我 要 这 样 一 个 模型 ， 然 后 XX 公司 就 告诉 我 老大 
* 说 要 这 样 一 个 模型 ， 这 样 一 个 顺序 ， 然 后 我 就 来 制造 
yA 
BenzModel benz = new BenzModel(); 
// 存 放 run 的 顺序 
ArrayList<String> sequence = new ArrayList<String>( 
sequence.add("engine boom"); // 客 户 要求 ，run 的 时 候 先 发 
sequence.add("start"); // 启 动 起 来 
sequence.add("stop"); // 开 了 一 段 就 停 下 来 
// 我 们 把 这 个 顺序 赋予 奔驰 车 
benz.setSequence(sequence); 
benz.run(); 























运行 结果 如 下 所 示 : 


驰 车 的 引擎 是 这 个 声音 的 … 


驰 车 跑 起 来 是 这 个 样子 的 … 


奔驰 车 应 该 这 样 停车 .… 





看 ， 我 们 组 装 了 这 样 的 一 辆 汽车 ， 满 足 了 xx 公司 的 需求 。 但 是 想 想 
我 们 的 需求 ， 汽 车 的 动作 执行 顺序 是 要 能 够 随意 调整 的 。 我 们 只 满足 了 
一 个 需求 ， 还 有 下 一 个 需求 呀 ， 然 后 是 第 二 个 宝马 模型 ， 只 要 局 动 、 停 
止 ， 其 他 的 什么 都 不 要 ;第 三 个 模型 ， 先 喇叭 ， 然 后 局 动 ， 然 后 停止 ; 
第 四 个 ..……... 直 到 把 你 壶 奖 为 止 ， 那 上 怎么 办 ? 我 们 就 一 个 一 个 地 来 写 场景 
类 满足 吗 ? 不 可 能 了 ， 那 我 们 要 想 办 法 来 解决 这 个 问题 ,， 有 了 ! 我 们 为 
每 种 模型 产品 模型 定义 一 个 建造 者 ， 你 要 啥 顺 序 直接 告诉 建造 者 ， 由 建 
造 者 来 建造 ， 于 是 乎 我 们 就 有 了 如 图 11-2 所 示 的 类 图 。 
















CarModel 










CarBuilder 








#yvoid start() 
#yvoid stop() 
#void alarml() 

Hyoid engineBoom!() 

+void run() 

+Vold setSequence(ArrayList sequence) 











+void setSequencelArrayList sequence) 
tCarModel getCarModell() 
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BMWModel 














奔驰 实现 类 











图 11-2 增加 了 建造 者 的 汽车 模型 类 图 


增加 了 一 个 CarBuilder 抽 象 类 ， 由 它 来 组 装 各 个 车 横 ， 要 什么 类 型 
什么 顺序 的 车 辆 模型 ， 都 由 相关 的 子 类 完成 。 首 先 编写 CarBuilder 代 


码 ， 如 代码 清单 11-5 所 示 。 


代码 清单 11-5 抽象 汽车 组 装 者 


public abstract class CarBuilder { 
// 建 造 一 个 模型 ， 你 要 给 我 一 个 顺序 要 求 ， 就 是 组 装 顺序 
public abstract void setSequence(ArrayList<String> sequence) 
// 设 置 完毕 顺 序 后 ， 就 可 以 直接 拿 到 这 个 车 辆 模型 
public abstract CarModel getCarModel(); 




















很 简单 ， 每 个 车 辆 模型 都 要 有 确定 的 运行 顺序 ， 然 后 才能 返回 一 人 
车 辆 模型 。 奔 驰 车 的 组 六 者 如 代码 清单 11-6 所 示 。 





代码 清单 11-6 奔驰 车 组 装 者 


public class BenzBuilder extends CarBuilder { 
private BenzModel benz = new BenzModel( ); 
public CarModel getCarModel() { 
return this.benz; 


public void setSequence(ArrayList<String> sequence) { 
this.benz.setSequence(sequence); 
} 





非常 简单 实用 的 程序 ， 给 定 一 个 汽车 的 运行 顺序 ， 然 后 就 返 
奔驰 车 ， 简 单 了 很 多 。 至 马车 的 组 闭 与 此 相同 ， 如 代码 清单 11-7 所 示 。 





代码 清单 11-7 宝马 车 组 装 者 


public class BMWBuilder extends CarBuilder { 
private BMwModel bmw = new BMwModel( ); 
public CarModel getCarModel() { 
return this.bmw; 


public void setSequence(ArrayList<String> sequence) { 


this.bmw.setSequence(sequence); 


两 个 组 装 者 都 完成 了 ， 我 们 再 来 看 看 xx 公司 的 需求 如 何 满足 ， 修 改 
一 下 场景 类 ， 如 代码 清单 11-8 所 示 。 


代码 清单 11-8 修改 后 的 场景 类 


public class Client { 
public static void main(String[] args) { 
XX 
* 客户 告诉 XX 公司 ,我 要 这 样 一 个 模型 ， 然 后 XX 公司 就 告诉 我 老大 
* 说 要 这 样 一 个 模型 ， 这 样 一 个 顺序 ， 然 后 我 就 来 制造 
A 
// 存 放 run 的 顺序 
ArrayList<String> sequence = new ArrayList<String>() 
sequence.add("engine boom"); // 客 户 要 求 ，run 时 候 时 候 先 ; 
sequence.add("start"); // 启 动 起 来 
sequence ,add("stop" ) ; // 开 了 一 段 就 停 下 来 
// 要 一 个 奔驰 车 : 
BenzBuilder benzBuilder = new BenzBuilder(); 
// 把 顺序 给 这 个 builder 类 ， 制 造 出 这 样 一 个 车 出 来 
benzBuilder.setSequence(sequence); 
// 制 造 出 一 个 奔驰 车 
BenzModel benz = (BenzModel)benzBuilder.getCarModell( 
// 奔 驰 车 跑 一 下 看 看 


benz .run() ; 






































一 


运行 结果 如 下 所 示 : 
奔驰 车 的 引擎 是 这 个 声音 的 .… 
奔驰 车 跑 起 来 是 这 个 样子 的 .… 





奔驰 车 应 该 这 样 停车 .. 





那 如 果 我 再 想 要 个 同样 顺序 的 宝马 车 呢 ? 很 简单 ， 再 次 修改 一 下 场 


景 类 ， 如 代码 清单 11-9 所 示 。 


代码 清单 11-9 相同 顺序 的 宝马 车 的 场景 类 


public class Client { 
public static void main(String[] args) { 


-一 


// 存 放 run 的 顺序 

ArrayList<String> sequence = new ArrayList<String>() 
sequence.add("engine boom"); // 客 户 要 求 ，run 的 时 候 先 发 i 
sequence.add("start"); // 启 动 起 来 
sequence.add("stop"); // 开 了 一 段 就 停 下 来 

// 要 一 个 奔驰 车 : 

BenzBuilder benzBuilder = new BenzBuilder(); 

// 把 顺序 给 这 个 builder 类 ， 制 造 出 这 样 一 个 车 出 来 
benzBuilder.setSequence(sequence); 

// 制 造 出 一 个 奔驰 车 

BenzModel benz = (BenzModel)benzBuilder.getCarModel( 
// 奔 驰 车 跑 一 下 看 看 

benz .run() ; 

// 按 照 同 样 的 顺序 ， 我 再 要 一 个 宝马 

BMWBuilder bmwBuilder = new BMWBuilder(); 
bmwBuilder.setSequence(sequence); 

BMwModel bmw = (BMwModel)bmwBuilder.getcarModel(); 
bmw.run( ); 





























运行 结果 如 下 所 示 : 





奔驰 车 的 引擎 是 这 个 声音 的 .. 
奔驰 车 跑 起 来 是 这 个 样子 的 .… 
奔驰 车 应 该 这 样 停车 .… 





宝马 车 的 引擎 是 这 个 声音 的 .… 


宝马 车 跑 起 来 是 这 个 样子 的 .… 


宝马 车 应 该 这 


样 停车 .. 











看 ， 同 样 运行 顺序 的 宝马 车 也 生产 出 来 了 ， 而 且 代 码 是 不 是 比 刚 开 
始 直 接 访问 产品 类 〈Procuct) 简单 了 很 多 。 我 们 在 做 项 目 时 ， 经 常会 有 
一 个 共识 : 需求 是 无 底 洞 ， 是 无 理性 的 ， 不 可 能 你 告诉 它 不 增加 需求 就 
不 增加 ， 这 4 个 过 程 (start、stop、alarm、engine boom) 按照 排列 组 合 
有 很 多 种 ，xx 公 司 可 以 随意 组 合 ， 它 要 什么 顺序 的 车 模 我 就 必须 生成 什 
么 顺序 的 车 模 ， 客 户 可 是 上 和 芝 ! 那 我 们 不 可 能 预知 他 们 要 什么 顺序 的 模 
型 呀 ， 怎 么 办 ? 封装 一 下 ， 找 一 个 导演 ， 指 挥 各 个 事件 的 先后 顺序 ， 然 
后 为 每 种 顺序 指定 一 个 代码 ， 你 说 一 种 我 们 立刻 就 给 你 生产 处 理 ， 好 方 
法 ， 历 害 ! 我 们 先 修改 一 下 类 图 ， 如 图 11-3 所 示 。 
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图 11-3 完整 汽车 模型 类 





类 图 看 着 复 森 了， 但 还 是 比较 简单 ， 我 们 增加 了 一 个 Director 类 ， 
负 贡 按照 指定 的 顺序 生产 模型 ， 其 中 方法 说 明 如 下 : 


~ 


e getABenzModel 方 法 


组 建 出 A 型 号 的 奔驰 车 辆 模型 ， 其 过 程 为 只 有 局 动 (start) 、 停 止 
(stop) 方法 ， 其 他 的 引擎 声音 、 喇 叭 都 没有 。 


e getBBenzModel 方 法 


组 建 出 B 型 号 的 奔驰 车 ， 其 过 程 为 先 发 动 引擎 (engine boom) ， 然 
后 启动 ， 再 然后 停车 ， 没 有 喇叭 。 


e getCBMWModel 方 法 


组 建 出 C 型 号 的 宝马 车 ， 其 过 程 为 先 喇叭 叫 一 下 (alarm) ， 然 后 启 
动 ， 再 然后 是 停车 ， 引 擎 不 和 受 鸣 。 


e getDBMWModel 方 法 


组 建 出 D 型 号 的 宝马 车 ， 其 过 程 就 一 个 启动 ， 然 后 一 路 跑 到 黑 ， 永 
动机 ， 没 有 停止 方法 ， 没 有 喇叭 ， 没 有 引擎 笑 鸣 。 








其 他 的 E 型 号 、F 型 号 ...... 可 以 有 很 多 ， 启 动 、 停 止 、 喇 叭 、 引 擎 纂 
鸣 这 4 个 方法 在 这 个 类 中 可 以 随意 地 自由 组 合 。Director 类 如 代码 清单 11- 
10 所 示 。 





代码 清单 11-10 导演 类 


public class Director { 
private ArrayList<String> sequence = new ArrayList(); 
private BenzBuilder benzBuilder = new BenzBuilder(); 
private BMWBuilder bmwBuilder = new BMWBuilder(); 


/* 
* A 类 型 的 奔驰 车 模型 ， 先 start， 然 后 stop， 其 他 什么 引擎 、 喇 叭 一 概 没 有 
*/ 
public BenzModel getABenzModel( ){ 
// 清 理 场 景 ， 这 里 是 一 些 初 级 程序 员 不 注意 的 地 方 
this.sequence.clear(); 
//ABenzModel1 的 执行 顺序 
this.sequence.add("start"); 
this.sequence.add("stop"); 
// 按 照 顺 序 返 回 一 个 奔驰 车 
this.benzBuilder.setSequence(this.sequence); 
return (BenzModel)this.benzBuilder .getCarModel( ); 





























* B 型 号 的 奔驰 车 模型 ， 是 先 发 动 引擎 ， 然 后 启动 ， 然 后 停止 ， 没 有 喇叭 
*/ 
public BenzModel getBBenzModel( ){ 

this.sequence.clear( ); 
this.sequence.add("engine boom"); 
this.sequence.add("start"); 
this.sequence.add("stop"); 
this.benzBuilder.setSequence(this.sequence); 
return (BenzModel)this.benzBuilder.getCarModel( ); 





} 
/* 
* C 型 号 的 宝马 车 是 先 按 下 喇叭 《炫耀 咏 ) ， 然 后 启动 ， 然 后 停止 
*/ 
public BMWwModel getCBMwModel( ){ 
this.sequence.clear(); 
this.sequence.add("alarm"); 
this.sequence.add("start"); 
this.sequence.add("stop"); 
this.bmwBuilder.setSequence(this.sequence); 
return (BMwModel)this.bmwBuilder.getCarModel(); 








* D 类 型 的 宝马 车 只 有 一 个 功能 ， 就 是 跑 ， 启 动 起 来 就 跑 ， 永 远 不 停止 
A 
public BMWwModel getDBMwModel( ){ 
this.sequence.clear( ); 
this.sequence.add("start"); 
this.bmwBuilder.setSequence(this.sequence); 
return (BMwModel)this.benzBuilder.getCarModel(); 








} 
/* 























* 这 里 还 可 以 有 很 多 方法 ， 你 可 以 先 停止 ， 然 后 再 启动 ， 或 者 一 直 停 着 不 动 ， 吏 ; 

















* 导演 类 嘛 ， 按 照 什么 顺序 是 导演 说 了 算 
*/ 














顺便 说 一 下 ， 大 家 看 一 下 程序 中 有 很 多 this 调 用 。 这 个 我 一 般 是 这 
样 要 求 项 目 组 成 员 的 ， 如 果 你 要 调用 类 中 的 成 员 变 量 或 方法 ， 需 要 在 前 
面 加 上 this 关 键 字 ， 不 加 也 能 正常 地 跑 起 来 ， 但 是 不 清晰 ， 加 上 this 关 键 
字 ， 我 吏 古 要 调用 本 类 中 的 成 员 变量 或 方法 ， 而 不 是 本 方法 中 的 一 个 变 
量 。 还 有 super 方 法 也 是 一 样 ， 是 调用 父 类 的 成 员 变 量 或 者 方法 ， 那 就 加 
上 这 个 关键 字 ， 不 要 省 略 ， 这 要 靠 约束 ， 还 有 就 是 程序 员 的 目 党 性 ， 他 
要 是 死 不 悔改 ， 那 咀 也 没 招 。 





























注意 ”上面 每 个 方法 都 有 一 个 this.sequence.clear()， 估 计 你 一 看 就 
明白 。 但 是 作为 一 个 系统 分 析 师 或 是 技术 经 理 一 定 要 告诉 项 目 成 员 ， 
ArrayList 和 HashMap 如 果 定 义 成 类 的 成 员 变量 ， 那 你 在 方法 中 的 调用 一 
定 要 做 一 个 clear 的 动作 ， 以 防止 数据 混乱 。 如 果 你 发 生 过 一 次 类 似 问 题 
的 话 ， 比 如 ArrayList 中 出 现 一 个 “出 乎 意料 ”的 数据 ， 而 你 又 花费 了 几 个 
通宵 才 解 决 这 个 问题 ， 那 你 会 有 很 深刻 的 印象 。 











有 了 这 样 一 个 导演 类 后 ， 我 们 的 场景 类 束 更 容易 处 理 了 ，xx 公 司 要 
A 关 型 的 奔驰 车 1 万 辆 ，B 类 型 的 奔驰 车 100 万 辆 ，C 关 型 的 宝马 车 1000 万 
辆 ，D 关 型 的 不 需要 ， 非 党 容易 处 理 ， 如 代码 清单 11-11 所 示 。 





代码 清单 11-11 导演 类 


public class Client { 


public static void main(String[] args) { 
Director director = new Director() ; 
//I 万 辆 A 类 型 的 奔驰 车 
for(int i=0;i<10000;i++){ 
director.getABenzModel().run(); 


} 

//109 万 辆 B 类 型 的 奔驰 车 

for(int i=0;i<1000000;i++){ 
director.getBBenzModel().run(); 


} 

//1000 万 辆 C 类 型 的 宝马 车 

for(int i=0;i<10000000;1i++){ 
director.getCBMwModel().run(); 

} 








清晰 、 简 单 吧 ， 我 们 写 程 序 重 构 的 最 终 目 的 就 是 : 简单 、 清 晰 。 代 
码 是 让 人 看 的 ， 不 是 写 完 就 完事 了 ， 我 一 直 在 教育 我 带 的 团队 成 员 ， 
Java 程 序 不 是 像 我 们 前 埋 写 二 进 制 代 码 、 汇 编 一 样 ， 写 完 基本 上 就 自己 
能 看 全 ， 别 人 看 就 跟 看 天 书 一 样 ， 现 在 的 高 级 语言 ， 要 像 写 中 文 汉字 一 
样 ， 你 写 的 ， 别 人 能 看 懂 。 这 就 是 建造 者 模式 。 














11.2 建造 者 模式 的 定义 


建造 者 模式 (Builder Pattern) 也 叫做 生成 器 模式 ， 其 定义 如 下 : 


Separate the construction of a complex object from its representation so 
that the same construction process can create different representations. (将 
一 个 复杂 对 象 的 构建 与 它 的 表示 分 离 
同 的 表示 。) 





， 使 得 同样 的 构建 过 程 可 以 创建 不 


建造 者 模式 的 通用 类 图 如 图 11-4 所 示 。 


+builder 。 
3 -| Builder 
Director Di Builder | 
+Construct() +BuildPart() 





ConcreteBuilder| . 
c= | 
EE | 


图 11-4 建造 者 模式 通用 类 图 
在 建造 者 模式 中 ， 有 如 下 4 个 角色 : 


e@ Product 产 品类 





通常 是 实 


实现 了 模板 方法 模式 ， 也 就 是 有 模板 方法 和 基本 方法 ， 








参考 第 10 章 的 模板 方法 模式 。 例 子 中 的 BenzModel 和 BMWIModel 束 属于 


产品 类 。 


Ne 


e Builder 抽 象 建造 者 


规范 产品 的 组 建 ， 一 般 是 由 子 类 实现 。 例 子 中 的 CarBuilder 就 属于 
抽象 建造 者 。 


e ConcreteBuilder 具 体 建 造 者 


实现 抽象 类 定义 的 所 有 方法 ， 并 且 返 回 一 个 组 建 好 的 对 象 。 例 子 中 
的 BenzBuilder 和 BMWBuilder 就 属于 具体 建造 者 。 


e Director 导 演 类 








负责 安排 已 有 模块 的 顺序 ， 然 后 告诉 Builder 开 始 建造 ， 在 上 面 的 例 
子 中 就 是 我 们 的 老大 ，xx 公 司 找到 老大 ， 说 我 要 这 个 或 那个 类 型 的 车 辆 
模型 ， 然 后 老大 就 把 命令 传递 给 我 ， 我 和 我 的 团队 就 开始 拼命 地 建造 ， 
于 是 一 个 项 目 建 设 完毕 了 。 


建造 者 模式 的 通用 源 代 码 也 比较 简单 ， 先 看 Product 类 ， 通 常 它 是 一 
个 组 合 或 继承 〈 如 模板 方法 模式 ) 产生 的 类 ， 如 代码 清单 11-12 所 示 。 
代码 清单 11-12 产品 类 


public class Product { 
public void doSomething()t{ 














// 独 立业 务 处 理 





抽象 建造 者 如 代码 清单 11-13 所 示 。 


代码 清单 11-13 抽象 建造 者 


public abstract class Builder { 
// 设 置 产品 的 不 同 部 分 ， 以 获得 不 同 的 产品 
public abstract void setPart(); 
// 建 造 产品 
public abstract Product buildProduct(); 








其 中 ，setPart 方 法 是 零件 的 配置 ， 什 么 是 零件 ?其 他 的 对 象 ， 获 得 
一 个 不 同和 零件 ， 或 者 不 同 的 装配 顺 友 束 可 能 产生 不 同 的 产品 。 具 体 的 建 
造 者 如 代码 清单 11-14 所 示 。 





代码 清单 11-14 具体 建造 者 


public class ConcreteProduct extends Builder f{ 
private Product product = new Product(); 
// 设 置 产品 零件 
public void setPart(){ 
/A 
* 产品 类 内 的 逻辑 处 理 
4 
































} 

// 组 建 一 个 产品 

public Product buildProduct() { 
return product; 

} 


-一 


再 要 注意 的 是 ， 如 果 有 多 个 产品 类 就 有 几 个 具体 的 建造 者 ， 而 且 这 
多 个 产品 类 具有 相同 接口 或 抽象 类 ， 参 考 我 们 上 面 的 例子 。 


导演 类 如 代码 清单 11-15 所 示 。 


代码 清单 11-15 导演 类 


public class Director { 
private Builder builder = new ConcreteProduct(); 
// 构 建 不 同 的 产品 
public Product getAProduct(){ 
builder.setPart(); 


* 设置 不 同 的 零件 ， 产 生 不 同 的 产品 
ph 











return builder.buildProduct(); 


一 
-一 


导演 类 起 到 封装 的 作用 ， 避 免 蝇 层 模块 深入 到 建造 者 内 部 的 实现 
类 。 当 然 ， 在 建造 者 模式 比较 庞大 时 ， 导 演 类 可 以 有 多 个 。 








11.3 建造 者 模式 的 应 用 


11.3.1 建造 者 模式 的 优点 


e 封装 性 


使 用 建造 者 模式 可 以 使 客户 端 不 必 知 道 产品 内 部 组 成 的 细节 ， 如 例 
子 中 我 们 就 不 需要 关心 每 一 个 具体 的 模型 内 部 是 如 何 实现 的 ， 产 生 的 对 
象 类 型 就 是 CarModel。 





e 建造 者 独立 ， 容 易 扩展 


BenzBuilder 和 BMWBuilder 是 相互 独立 的 ， 对 系统 的 扩展 非常 有 
利 。 


e 便于 控制 细节 风险 


由 于 具体 的 建造 者 是 独立 的 ， 因 此 可 以 对 建造 过 程 逐 步 细 化 ， 而 不 
对 其 他 的 模块 产生 任何 影响 。 


11.3.2 建造 者 模式 的 使 用 场景 


e 相同 的 方法 ， 不 同 的 执行 顺序 ， 产 生 不 同 的 事件 结果 时 ， 可 以 采 


用 建造 者 模式 。 


e 多 个 部 件 或 零件 ， 痢 可 以 装配 到 一 个 对 象 中 ， 但 是 产生 的 运行 结 
果 又 不 相同 时 ， 则 可 以 使 用 该 模式 。 





e 产品 类 非常 复杂 ， 或 者 产品 类 中 的 调用 顺序 不 同 产生 了 不 同 的 效 
， 这 个 时 候 使 用 建造 者 模式 非常 合适 。 





ZN 
CC 


e 在 对 象 创建 过 程 中 会 使 用 到 系统 中 的 一 些 其 他 对 象 ， 这 些 对 象 在 
产品 对 象 的 创建 过 程 中 不 易 得 到 时 ， 也 可 以 采用 建造 者 模式 封装 该 对 象 
的 创建 过 程 。 该 种 场景 只 能 是 一 个 补偿 方法 ， 因 为 一 个 对 象 不 容易 获 
得 ， 而 在 设计 阶段 竟然 没有 发 觉 ， 而 要 通过 创建 者 模式 柔 化 创建 过 程 ， 
本 刁 已 经 违反 设计 的 最 初 目标 。 





11.3.3 建造 者 模式 的 注意 事项 





建造 者 模式 关注 的 是 零件 类 型 和 装配 工艺 (顺序 ) ， 这 是 它 与 工 | 
方法 模式 最 大 不 同 的 地 方 ， 虽 然 同 为 创建 类 模式 ， 但 是 注重 点 不 同 。 











11.4 建造 者 模式 的 扩展 


己 经 不 用 扩展 了 ， 因 为 我 们 在 汽车 模型 制造 的 例子 中 已 经 对 建造 者 
模式 进行 了 扩展 ， 引 入 了 模板 方法 模式 。 可 能 大 家 会 比较 括 惑 ， 为 什么 
在 其 他 介绍 设计 模式 的 书籍 上 创建 者 模式 并 不 是 这 样 说 的 ? 读者 请 注 
意 ， 建 造 者 模式 中 还 有 一 个 角色 没有 说 明 ， 就 是 零件 ， 建 造 者 怎么 去 建 
造 一 个 对 象 ? 是 零件 的 组 装 ， 组 闭 顺 序 不 同 对 象 效能 也 不 同 ， 这 才 是 建 
造 者 模式 要 表达 的 核心 意义 ， 而 怎么 才能 更 好 地 达到 这 种 效果 呢 ? 引入 
模板 方法 模式 是 一 个 非常 简单 而 有 效 的 办 法 。 





大 家 看 到 这 里 估计 就 开始 犯 吐 叶 了， 这 个 建造 者 模式 和 工厂 模式 非 
常 相似 呀 ， 是 的 ， 非 常 相似 ， 但 是 记 住 一 点 你 就 可 以 游 力 有 余地 使 用 
了 : 建造 者 模式 最 主要 的 功能 是 基本 方法 的 调用 顺序 安排 ， 也 就 是 这 些 
基本 方法 已 经 实现 了 ， 通 俗 地 说 就 是 零件 的 装配 ， 顺 序 不 同 产 生 的 对 象 
也 不 同 ， 而 工 广 方法 则 重点 是 创建 ， 创 建 零件 是 它 的 主要 职责 ， 组 装 顺 
序 则 不 是 它 关 心 的 。 











11.5 最 佳 实践 





再 次 说 明 ， 在 使 用 建造 者 模式 的 时 候 考虑 一 下 模板 方法 模式 ， 别 阪 
立地 思考 一 个 模式 ， 伪 化 地 套用 一 个 模式 会 让 你 受害 无 穷 ! 


如 末 你 已 经 看 懂 本 书 举 的 例子 ， 并 认可 这 种 建造 者 模式 ， 那 你 束 放 
心 使 用 ， 比 单独 使 用 建造 者 高 效 、 简 洁 得 多 。 


第 12 章 ”代理 模式 


12.1 我 是 游戏 至 章 


2007 年 ， 感 觉 很 无 聊 ， 于 是 就 玩 了 一 段 时 间 的 网 络 游戏 ， 游 戏 名 就 
不 说 了 ， 反 正 就 是 打 怪 、 升 级 、 砍 人 、 科 人 砍 ， 然 后 继续 打 怪 、 升 级 、 
打 怪 、 升 级 ..…… 我 伦 了 两 个 月 的 时 间 升 到 80 级 ， 已 经 很 有 成 就 感 了 ， 但 
是 还 会 被 人 杀 死 ， 高 手 到 处 都 是 ，GM (Game Master， 游 戏 管理 员 ) 也 
不 管 ， 对 于 咱 这 种 非 RMB 玩 家 基本 上 都 是 懒得 搭理 。 在 这 段 时间 我 是 
体会 到 网 络 游戏 的 乐 与 苦 ， 参 与 家 族 〈 工 会 ) 攻 城 ， 胜 利 后 那 叫 一 个 乐 
呀 ， 感 觉 自己 真是 一 个 “狂暴 战士 >， 无 往 不 胜 ! 那 苦 是 什么 呢 ? 就 是 升 
级 ， 为 了 升 一 级 ， 就 要 到 处 杀 怪 ， 做 任务 ， 那 个 游戏 还 很 变态 ， 外 挂 管 
得 很 严 ， 基 本 上 出 个 外 挂 ， 没 两 天 就 开始 封 账号 ， 不 敢 用 ， 升 级 基本 上 
都 要 靠 自己 手打 ， 累 呀 ! 我 曾经 的 记录 是 连 着 打 了 23 个 小 时 ， 睡 觉 在 梦 
中 还 和 大 BOSS 在 PK。 有 这 样 一 段 经 历 还 是 很 有 意思 的 ， 作 为 架构 师 是 
不 是 可 以 把 这 段 经 历 通过 架构 的 方式 记录 下 来 呢 ? 当然 可 以 了 ， 我 们 把 
这 段 打 游 戏 的 过 程 系统 化 ， 非 常 简单 的 一 个 过 程 ， 如 图 12-1 所 示 。 








<<interface>> 


ey IGame Player 
Clien 。 
tlogin(String user, String password) 


Hvoid kiIBoss() 
Hvold uperade() 





GamePlayer 


图 12-1 游戏 过 程 





太 简 单 了 ， 定 义 一 个 接口 [GamePlayer， 是 所 有 喜爱 网 络 游戏 的 玩 
家 ， 然 后 定义 一 个 具体 的 实现 类 GamePlayer， 实 现 每 个 游戏 爱好 者 为 了 
玩 游戏 要 执行 的 功能 。 代 码 也 非常 简单 ， 我 们 先 来 看 IGamePlayer， 如 
代码 清单 12-1 所 示 。 


代码 清单 12-1 游戏 者 接口 


public interface IGamePlayer { 
// 登 录 游 戏 
public void login(String user,String password); 
// 杀 怪 ， 网 络 游 戏 的 主要 特色 
public void killBoss(); 
// 升 级 
public void upgrade( ); 





非常 简单 ， 定 义 了 三 个 方法 ， 分 别 是 我 们 在 网 络 游戏 中 最 常用 的 功 
能 : 登录 游戏 、 杀 怪 和 升级 ， 其 实现 类 如 代码 清单 12-2 所 示 。 


代码 清单 12-2 游戏 者 


public class GamePlayer implements IGamePlayer { 
private String name = ""; 
// 通 过 构造 函数 传递 名 称 
public GamePlayer(String _name)t{ 
this.name = _name， 





} 

// 打 怪 ， 最 期 望 的 就 是 杀 老 怪 

public void killBoss() { 
System.out.println(this.name +“" 在 打 怪 !")， 




















} 
// 进 游戏 之 前 你 肯定 要 登录 吧 ， 这 是 一 个 必要 条 件 
public void login(String user, String password) { 


System.out .println(" 登 录 名 为 "+user+" 的 用 户 "+this ,name+' 





// 升 级 ， 升 级 有 很 多 方法 ， 花 钱 买 是 一 种 ， 做 任务 也 是 一 种 
public void upgrade() { 


站 





System.out.printJlIn(this.name + " 又 升 了 一 级 ! 








"); 


在 实现 类 中 通过 构造 函数 传递 进来 玩家 姓名 ， 方 便 进行 后 期 的 调试 
工作 。 我 们 通过 一 个 场景 类 来 模拟 这 样 的 游戏 过 程 ， 如 代码 清单 12-3 所 


不 。 


代码 清单 12-3 场景 类 


public class Client { 
public static void main(String[] args) { 
// 定 义 一 个 痴迷 的 玩家 





IGamePlayer player = new GamePlayer(" 张 三 "); 


// 开 始 打 游戏 ， 记 下 时 间 截 


System.out.println(" 开 始 时 间 是 : 2009-8-25 10: 


player .login("zhangSan", "password"); 
// 开 始 杀 怪 

player .killBoss(); 

// 升 级 

player .upgrade( )，; 

// 记 录 结 束 游戏 时 间 








System.out.println(" 结 束 时 间 是 : 2009-8-26 03: 


45"); 


40"); 


程序 记录 了 游戏 的 开始 时 间 和 结束 时 间 ， 同 时 也 记录 了 在 游戏 过 程 
中 都 需要 做 什么 事情 ， 运 行 结果 如 下 : 


开始 时 间 是 : 2009-8-25 10:45 








登录 名 为 zhangSan 的 用 户 张 三 登 录 成 功 ! 
张 三 在 打 怪 ! 
张 三 又 升 了 一 级 ! 


结束 时 间 是 : 2009-8-26 03:40 





运行 结果 也 是 我 们 想 要 的 ， 记 录 我 这 段 时 间 的 网 游 生涯 。 心 理学 家 
告诉 我 们 ， 人 类 对 于 苦难 的 记忆 比 对 喜悦 的 记忆 要 深刻 ， 但 是 人 类 对 于 
喜悦 是 “ 趋 利 ”性 的 ， 每 个 人 都 想 Happy， 都 不 想 让 苦难 靠近 ， 要 想 获得 
幸福 ， 苦 难 也 是 在 所 难免 的 ， 我 们 的 网 游 生涯 也 是 如 此 。 游 戏 打 时 间 长 
了 ， 腰 酸 背 痛 、 眼 睛 和 干涩、 手臂 酸 及 ， 等 等 ， 也 就 是 网 络 成 瘾 综合 症 都 
出 来 了 。 其 结果 就 类 似 吃 了 那个 “一 日 丧命 散 ”，“ 筋 脉 逆流 ， 胡 思 乱 
想 ， 而 致 走火 入 魔 "。 那 怎么 办 呢 ? 我 们 想 玩 游戏 ， 但 又 不 想 碰 触 到 游 
戏 中 的 烦恼 ， 如 何 解 决 呢 ? 有 办 法 ， 现 在 游戏 代 练 的 公司 非常 多 ， 我 把 
自己 的 账号 交 给 代 练 人 员 ， 由 他 们 去 帮 我 升级 ， 去 打 怪 ， 非 常 好 的 想 
法 ， 我 们 来 修改 一 下 类 图 ， 如 图 12-2 所 示 。 


<<mterface>> 
IGamePlayer 


Client tlogin(String user, String password) 





tvold killBoss() 
+vold upgrade() 








GamePlayer 


= 
+CGamePlayer(Strng name) 


GamePlayerProxy 


| 
+CGamePlayerProxy(IGamePlayer gamePlayer) 





图 12-2 游戏 代 练 帮忙 打 怪 


在 类 图 中 增加 了 一 个 GamePlayerProxy 类 来 代表 游戏 代 练 者 ， 它 也 
不 能 有 作 整 的 方法 呀 ， 游 戏 代 练 者 也 是 手动 打 怪 呀 ， 因 此 同样 继承 
IGamePlayer 接 口 ， 其 实现 如 代码 清单 12-4 所 示 。 


代码 清单 12-4 代 练 者 


public class GamePlayerProxy implements IGamePlayer { 
private IGamePlayer gamePlayer = null; 
// 通 过 构造 函数 传递 要 对 谁 进行 代 练 
public GamePlayerProxy(IGamePlayer _gamePlayer)t{ 
this.gamePlayer = _gamePlayer; 


} 

// 代 练 杀 怪 

public void killBoss() { 
this.gamePlayer .killBoss(); 


} 

// 代 练 登录 

public void login(String user, String password) { 
this.gamePlayer.1login(user, password); 


} 

// 代 练 升级 

public void upgrade() { 
this.gamePlayer .upgrade( ); 








很 简单 ， 首 先 通 过 构造 函数 说 明 要 代 谁 打 怪 升级 ， 然 后 通过 手动 开 
始 代用 户 打 怪 、 升 级 。 场 景 类 Client 代 码 也 稍 作 改 动 ， 如 代码 清单 12-5 
所 示 。 


代码 清单 12-5 改进 后 的 场景 类 


public class Client { 

public static void main(String[|] args) { 
// 定 义 一 个 奖 迷 的 玩家 
IGamePlayer player = new GamePlayer(" 张 三"); 
// 然 后 再 定义 一 个 代 练 者 
IGamePlayer proxy = new GamePlayerProxy(player); 
// 开 始 打 游 戏 ， 记 下 时 间 堆 
System,.out.printlLn(" 开 始 时 间 是 : 2009-8-25 10:45"); 
proxy.1login("zhangSan", "password"); 
// 开 始 杀 怪 
proxy.killBoss(); 
// 升 级 
proxy.upgrade( )， 
// 记 录 结 束 游戏 时 间 
System,out.printlLn(" 结 束 时 间 是 : 2009-8-26 03:;40"); 




















一 


运行 结果 也 完全 相同 ， 还 是 张 三 这 个 用 户 在 打 怪 ， 运 行 结果 如 下 : 


开始 时 间 是 : 2009-8-25 10:45 








登录 名 为 zhangSan 的 用 户 张 三 登 录 成 功 ! 
张 三 在 打 怪 ! 





张 三 又 升 了 一 级 ! 


结束 时 间 是 : 2009-8-26 03:40 





12.2 代理 模式 的 定义 





代理 模式 (Proxy Pattern) 是 一 个 使 用 率 非 常 蜗 的 模式 ， 其 定义 如 
下 : 


Provide a surrogate or placeholder for another object to control access to 


it.〔 为 其 他 对 象 提供 一 种 代理 以 控制 对 这 个 对 象 的 访问 。) 


代理 模式 的 通用 类 图 如 图 12-3 所 示 。 





图 12-3 代理 模式 的 通用 类 图 





代理 模式 也 叫做 委托 模式 ， 它 是 一 项 基本 设计 技巧 。 许 多 其 他 的 模 
式 ， 如 状态 模式 、 集 略 模式 、 访 问 者 模 陈 本 质 上 是 在 更 特殊 的 场合 采用 
了 委托 模式 ， 而 且 在 日 第 的 应 用 中 ， 代 理 模式 可 以 提供 非常 好 的 访问 控 


制 。 在 一 些 著 名 开源 软件 中 也 经 常见 到 它 的 号 影 ， 如 Struts2 的 Form 元 素 
映射 就 采用 了 代理 模式 〈 谁 确 地 说 是 动态 代理 模式 ) 。 我 们 先 看 一 下 类 
图 中 的 三 个 角色 的 定义 : 


e Subject 抽 象 主题 角色 


抽象 主题 类 可 以 是 抽象 类 也 可 以 是 接口 ， 是 一 个 最 普通 的 业务 类 型 
定义 ， 无 特殊 要 求 。 


e RealSubject 具 体 主 题 角色 


也 叫做 被 委托 角色 、 被 代理 角色 。 它 才 是 多 大 头 ， 是 业务 逻辑 的 有 具 
体 执行 者 。 


e Proxy 代 理 主题 角色 


也 叫做 委托 类 、 代 理 类 。 它 负责 对 真实 角色 的 应 用 ， 把 所 有 抽象 主 
题 类 定义 的 方法 限制 委托 给 真实 主题 角色 实现 ， 并 且 在 真实 主题 角色 处 
理 完毕 前 后 做 预 处理 和 善后 处 理工 作 。 








我 们 首先 来 看 Subject 抽 象 主题 类 的 通用 源码 ， 如 代码 清单 12-6 所 
不 。 
代码 清单 12-6 抽象 主题 类 


public interface Subject { 
// 定 义 一 个 方法 








public void request(); 


在 接口 中 我 们 定义 了 一 个 方法 request 来 作为 方法 的 代表 ， 
RealSubject 对 它 进行 实现 ， 如 代码 清单 12-7 所 示 。 


代码 清单 12-7 真实 主题 类 


public class RealSubject implements Subject { 
// 实 现 方法 
public void request() { 
// 业 务 逻 辑 处 理 
} 
































RealSubject 是 一 个 正常 的 业务 实现 类 ， 代 理 模式 的 核心 束 在 代理 类 
上 ， 如 代码 清单 12-8 所 示 。 


代码 清单 12-8 代理 类 


public class Proxy implements Subject { 
// 要 代理 哪个 实现 类 
private Subject subject = null; 
// 默 认 被 代理 者 
public Proxy(){ 
this.subject = new Proxy(); 


} 
// 通 过 构造 函数 传递 代理 者 
public Proxy(Object...objects ){ 

































































} 

// 实 现 接口 中 定义 的 方法 

public void request() { 
this.beforel( ); 
this.subject.request(); 
this.after(); 

















} 

// 预 处 理 

private void before(){ 
//do something 

} 

















// 善 后 处 理 
private void after(){ 

//do something 
} 





看 到 这 里 ， 大 家 别 惊讶 ， 为 什么 会 出 现 before 和 after 方 法 ， 继 续 看 
下 去 ， 这 是 一 个 “引子 ”， 能 够 引出 一 个 轨 新 的 编程 模式 。 


一 个 代理 类 可 以 代理 多 个 被 委托 者 或 被 代理 者 ， 因 此 一 个 代理 类 具 
体 代理 哪个 真实 主题 角色 ， 是 由 场景 类 决定 的 。 当 然 ， 最 简单 的 情况 就 
古 一 个 主题 类 和 一 个 代理 类 ， 这 是 最 简洁 的 代理 模式 。 在 通常 情况 下 ， 
一 个 接口 只 需要 一 个 代理 类 就 可 以 了 ， 有 具体 代理 哪个 实现 类 由 高 层 模块 
来 决定 ， 也 就 是 在 代理 类 的 构造 函数 中 传递 被 代理 者 ， 例 如 我 们 可 以 在 
代理 类 Proxy 中 增加 如 代码 清单 12-9 所 示 的 构造 函数 。 











代码 清单 12-9 代理 的 构造 函数 


public Proxy(Subject _subject){ 
this.subject = _Ssubject 
} 


你 要 代理 谁 束 产生 该 代理 的 实例 ， 然 后 把 被 代理 者 传递 进来 ， 该 模 
式 在 实际 的 项 目 应 用 中 比较 广泛 。 


12.3 代理 模式 的 应 用 


12.3.1 代理 模式 的 优点 


真实 的 角色 就 是 实现 实际 的 业务 逻辑 ， 不 用 关心 其 他 非 本 职责 的 事 
务 ， 通 过 后 期 的 代理 完成 一 件 事务 ， 附 带 的 结果 就 是 编程 简洁 清晰 。 





e 局 扩展 性 


具体 主题 角色 是 随时 都 会 发 生变 化 的 ， 只 要 它 实 现 了 接口 ， 朋 管 它 
如 何 变化 ， 都 逃 不 脱 如 来 佛 的 手掌 (接口 )， 那 我 们 的 代理 类 完全 就 可 
以 在 不 做 任何 修改 的 情况 下 使 用 。 


e 智能 化 


这 在 我 们 以 上 的 讲解 中 还 没有 体现 出 来 ， 不 过 在 我 们 以 下 的 动态 代 
理 音节 中 你 就 会 看 到 代理 的 智能 化 有 兴趣 的 读者 也 可 以 看 看 Struts 是 如 
何 把 表单 元 素 映 射 到 对 象 上 的 。 





12.3.2 代理 模式 的 使 用 场景 


我 相信 第 一 次 接触 到 代理 模式 的 读者 肯定 很 者 问 ， 为 什么 要 用 代理 
呀 ? 想 想 现实 世界 吧 ， 打 官司 为 什么 要 找 个 律师 ? 因为 你 不 想 参 与 中 间 
过 程 的 是 是 非 非 ， 只 要 完成 目 己 的 答辩 惑 成 ， 其 他 的 比如 事前 调 奋 、 事 
后 退 查 部 由 律师 来 搞定 ， 这 就 是 为 了 减轻 你 的 负担 。 代 理 模 式 的 使 用 场 
景 非常 多 ， 大 家 可 以 看 看 Spring AOP， 这 是 一 个 非常 典型 的 动态 代理 。 





12.4 代理 模式 的 扩展 
12.4.1 普通 代理 


在 网 络 上 代理 服务 器 设置 分 为 透明 代理 和 普通 代理 ， 是 什么 意思 

呢 ? 透明 代理 就 是 用 户 不 用 设置 代理 服务 器 地 址 ， 就 可 以 直接 访问 ， 也 
就 是 说 代理 服务 器 对 用 户 来 说 是 透明 的 ， 不 用 知道 它 存 在 的 ;普通 代理 
则 是 震 要 用 户 自己 设置 代理 服务 器 的 IP 地 址 ， 用 户 必 须知 道 代 理 的 存 

在 。 我 们 设计 模式 中 的 普通 代理 和 强制 代理 也 是 类 似 的 一 种 结构 ， 普 通 

代理 就 是 我 们 要 知道 代理 的 存在 ， 也 就 是 类 似 的 GamePlayerProxy 这 个 
类 的 存在 ， 然 后 才能 访问 ， 强制 代 理 则 是 调用 者 直接 调用 真实 角色 ， 而 
不 用 关心 代理 是 否 存 在 ， 其 代理 的 产生 是 由 真实 角色 决定 的 ， 这 样 的 解 
释 还 是 比较 复杂 ， 我 们 还 是 用 实例 来 讲解 。 





首先 说 普通 代理 ， 它 的 要 求 就 是 客户 端 只 能 访问 代理 角色 ， 而 不 能 
访问 真实 角色 ， 这 是 比较 简单 的 。 我 们 以 上 面 的 例子 作为 扩展 ， 我 自己 
作为 一 个 游戏 玩家 ， 我 肯定 自己 不 练 级 了 ， 也 就 是 场景 类 不 能 再 直接 
ew 一 个 GamePlayer 对 象 了 ， 它 必须 由 GamePlayerProxy 来 进行 模拟 场 
景 ， 类 图 修改 如 图 12-4 所 示 。 












<<interface>> 
ICamePlayer 










+login(String user, Strmg password) 
+void killBoss() 
+vold uperade() 


" a 











| | GamePlayer 

















+GamePlayer (IGamePlayer gamePlayer, Strng_name) 





GamePlayerProxy 
= 


+GamePlayerProxy (Strng _name) 





图 12-4 普通 代理 类 图 





改动 很 小 ， 仅 仅 修改 了 两 个 实现 类 的 构造 函数 ，GamePlayer 的 构造 
函数 增加 了 _gamePlayer 参 数 ， 而 代理 角色 则 只 要 传 入 代理 者 名 字 即 
可 ， 而 不 需要 说 是 蔡 哪个 对 象 做 代理 。GamePlayer 类 如 代码 清单 12-10 
所 示 。 





代码 清单 12-10 普通 代理 的 游戏 者 


public class GamePlayer implements IGamePlayer { 
private String name = ""; 
// 构 造 函 数 限制 谁 能 创建 对 象 ， 并 同时 传递 姓名 
public GamePlayer(IGamePlayer _gamePlayer,String _name) thro 
if(_gamePlayer == null ){ 
throw new Exception(" 不 能 创建 真实 角色 ! ")， 
}elsef 
this.name = _name， 
} 


} 
// 打 怪 ， 最 期 望 的 就 是 杀 老 怪 
public void killBoss() { 

















System.out.println(this.name + "在 打 怪 ! ")， 

















} 

// 进 游戏 之 前 你 肯定 要 登录 吧 ， 这 是 一 个 必要 条 件 

public void login(String user, String password) { 
System.out.println(" 登 录 名 为 "+user + "的 用 户 " + this.ne 


} 
// 升 级 ， 升 级 有 很 多 方法 ， 花 钱 买 是 一 种 ， 做 任务 也 是 一 种 
public void upgrade() { 
System.out.println(this.name + " 又 升 了 一 级 ! ")) 
} 











在 构造 函数 中 ， 传 递 进 来 一 个 IGamePlayer 对 象 ， 检 查 谁 能 创建 真 
实 的 角色 ， 当 然 还 可 以 有 其 他 的 限制 ， 比 如 类 名 必须 为 Proxy 类 等 ， 读 
者 可 以 根据 实际 情况 进行 扩展 。GamePlayerProxy 如 代码 清单 12-11 所 


人 钞 。 





代码 清单 12-11 普通 代理 的 代理 者 


public class GamePlayerProxy implements IGamePlayer { 
private IGamePlayer gamePlayer = null; 
// 通 过 构造 函数 传递 要 对 谁 进行 代 练 
public GamePlayerProxy(String name ){ 
try { 











gamePlayer = new GamePlayer (this,name); 
} catch (Exception e) { 

// TODO 异常 处 理 
} 


了 

// 代 练 杀 怪 

public void killBoss() { 
this.gamePlayer .killBoss(); 


























} 

// 代 练 登录 

public void login(String user, String password) { 
this.gamePlayer.1login(user, password); 


} 

// 代 练 升级 

public void upgrade() { 
this.gamePlayer .upgrade( ); 

} 








仅仅 修改 了 构造 沙 数 ， 传 递 进来 一 个 代理 者 名 称 ， 即 可 进行 代理 ， 
在 这 种 改造 下 ， 系 统 更 加 简洁 了 ， 调 用 者 只 知道 代理 存在 就 可 以 ， 不 用 
知道 代理 了 谁 。 同 时 场景 类 也 稍 作 改动 ， 如 代码 清单 12-12 所 示 。 


代码 清单 12-12 普通 代理 的 场景 类 


public class Client { 
public static void main(String[] args) { 

// 然 后 再 定义 一 个 代 练 者 
IGamePlayer proxy = new GamePlayerProxy(" 张 三 ")， 
// 开 始 打 游 戏 ， 记 下 时 间 戳 
System.out.println(" 开 始 时 间 是 : 2009-8-25 10:45"); 
proxy.1login("zhangSan", "password"); 
// 开 始 杀 怪 
proxy.killBoss(); 
// 升 级 
proxy.upgrade( ) ; 
// 记 录 结 束 游戏 时 间 
System,out.println(" 结 束 时 间 是 : 2009-8-26 03;40"); 








ww 


运行 结果 完全 相同 。 在 该 模式 下 ， 调 用 者 只 知 代理 而 不 用 知道 真实 
的 角色 是 谁 ， 屏 殴 了 真实 角色 的 变更 对 高 层 模 块 的 影响 ， 真 实 的 主题 角 
色 想 怎么 修改 就 怎么 修改 ， 对 高 层次 的 模块 没有 任何 的 影响 ， 只 要 你 实 
现 了 接口 所 对 应 的 方法 ， 该 模式 非常 适合 对 扩展 性 要 求 较 高 的 场合 。 当 
然 ， 在 实际 的 项 目 中 ， 一 般 都 是 通过 约定 来 禁止 new 一 个 真实 的 角色 ， 
这 也 是 一 个 非常 好 的 方案 。 














注意 通 代 理 模式 的 约束 问题 ， 尺 量 通 过 团队 内 的 编程 规范 类 


约束 ， 因 为 每 一 个 主题 类 是 可 被 重用 的 和 可 维护 的 ， 使 用 技术 约束 的 方 
式 对 系统 维护 是 一 种 非常 不 利 的 因素 。 


12.4.2 强制 代理 


强制 代理 在 设计 模式 中 比较 另类 ， 为 什么 这 么 说 呢 ? 一 般 的 思维 都 
是 通过 代理 找到 真实 的 角色 ， 但 是 强制 代理 却 是 要 “强制 ”， 你 必须 通过 
真实 角色 碍 找到 代理 角色 ， 人 否则 你 不 能 访问 。 有 者 管 你 是 通过 代理 类 还 是 
通过 直接 new 一 个 主题 角色 类 ， 都 不 能 访问 ， 只 有 通过 真实 角色 指定 的 
代理 类 才 可 以 访问 ， 也 就 是 说 由 真实 角色 管理 代理 角色 。 这 么 说 吧 ， 高 
层 模 块 new 了 一 个 真实 角色 的 对 象 ， 返 回 的 却 是 代理 角色 ， 这 就 好 比 是 
你 和 一 个 明星 比较 熟 ， 相 互 认识 ， 有 件 事 情 你 需要 向 她 确认 一 下 ， 于 是 
你 就 直接 拨 通 了 明星 的 电话 : 











“ 眼 ， 沙 比 蚜 ， 我 要 见 一 下 xxx 导 演 ， 你 帮 下 忙 了 ! ” 

“不 行 呀 有 娶 哥 ， 我 这 儿 天 很 性 是， 你 找 我 的 经 纪 人 吧 .………… 
郁 间 了 吧 ， 你 是 想 直 接 绕 过 她 的 代理 ， 谁 知道 返回 的 还 是 她 的 代 
这 就 是 强制 代理 ， 你 可 以 不 用 知道 代理 存在 ,但 是 你 的 所 作 所 为 还 


是 需要 代理 为 你 提供 。 我 们 把 上 面 的 例子 稍 作 修 改 就 可 以 完成 ， 如 图 
12-5 所 示 。 


<<interface>> 
IJGamePlayer 


= 一 一 
- +login(String user, String password) 
Client +void killBoss() 
+void upgrade() 
+GamePlayer getProxy() 






Game PlayerProxy 
一 == 一 一 一 一 


+GamePlayerProxy(IGamePlayer gamePlayer) 





图 12-5 强制 代理 类 图 


在 接口 上 增加 了 一 个 getProxy 方 法 ， 真 实 角 色 GamePlayer 可 以 指定 
一 个 自己 的 代理 ， 除 了 代理 外 谁 都 不 能 访问 。 我 们 来 看 代码 ， 先 看 
IGamePlayer 接 口 ， 如 代码 清单 12-13 所 示 。 


代码 清单 12-13 强制 代理 的 接口 类 


public interface IGamePlayer { 
// 登 录 游 戏 
public void login(String user,String password); 
// 杀 怪 ， 这 是 网 络 游戏 的 主要 特色 
public void killBoss(); 
// 升 级 
public void upgrade( ); 
// 每 个 人 都 可 以 找 一 下 自己 的 代理 
public IGamePlayer getProxy(); 








仅仅 增加 了 一 个 getProxy 方 法 ， 指 定 要 访问 上 自己 必须 通过 哪个 代 


理 ， 实 现 类 也 要 做 适当 的 修改 ， 先 看 真实 角色 GamePlayer， 如 代码 清单 


12-14 所 示 。 


代码 清单 12-14 强制 代理 的 真实 角色 


public class GamePlayer Ss IGamePlayer { 
private String name = ""; 
// 我 的 代理 是 谁 
private IGamePlayer proxy = null; 
public GamePlayer(String _name ){ 
this.name = _name， 


} 
// 找 到 自己 的 代理 
public IGamePlayer getProxy(){ 
this.proxy = new GamePlayerProxy(this); 
return this.proxy; 


} 
// 打 怪 ， 最 期 望 的 就 是 杀 老 怪 
public void killBoss() { 
if(this.isProxy())t{ 
System.out.printlLn(this.name +“" 在 打 怪 !")， 















































}elsef{ 


} 


} 
// 进 游戏 之 前 你 肯定 要 登录 吧 ， 这 是 一 个 必要 条 件 
public void login(String user, String password) { 
if(this.isPproxy())t{ 
System.out.println(" 登 录 名 为 "+user+" 的 用 户 "+th: 




















System.out.println(" 请 使 用 指定 的 代理 访问 " )， 























}elsef 




















System.out .println(" 请 使 用 指定 的 代理 访问 ");，; 








} 


} 
// 升 级 ， 升 级 有 很 多 方法 ， 花 钱 买 是 一 种 ， 做 任务 也 是 一 种 
public void upgrade() { 
if(this.isPproxy())t{ 
System.out.printin(this.name + " 又 升 了 一 级 !" 








}elsef 


} 


} 

// 校 验 是 否 是 代理 访问 

private boolean isProxy(){ 
if(this.proxy == null)t{ 


























System.out.println(" 请 使 用 指定 的 代理 访问 ")， 























return false; 
}elsef 


} 


return true; 





增加 了 一 个 私有 方法 ， 检 查 是 否 是 自己 指定 的 代理 ， 是 指定 的 代理 





则 允许 访问 ， 否 则 不 允许 访问 。 我 们 再 来 看 代理 角色 ， 如 代码 清单 12- 
15 所 示 。 


代码 清单 12-15 强制 代理 的 代理 类 


public class GamePlayerProxy implements IGamePlayer { 


private IGamePlayer gamePlayer = null; 


// 构 造 函 数 传递 用 户 名 

public GamePlayerProxy(IGamePlayer _gamePlayer)t{ 
this.gamePlayer = _gamePlayer; 

} 

// 代 练 杀 怪 





public void killBoss() { 
this.gamePlayer .killBoss(); 


} 

// 代 练 登录 

public void login(String user, String password) { 
this.gamePlayer.1login(user, password); 


} 

// 代 练 升级 

public void upgrade() { 
this.gamePlayer .upgrade( ); 


} 

// 代 理 的 代理 暂时 还 没有 ， 就 是 自己 

public IGamePlayer getProxy(){ 
return this,; 

} 






































代理 角色 也 可 以 再 次 被 代理 ， 这 里 我 们 就 没有 继续 延伸 下 去 了 ， 碍 


找 代理 的 方法 就 返回 上 自己 的 实例 。 代 码 都 写 完毕 了 ， 我 们 和 匈 按照 营 规 的 





思路 来 运行 一 下 ， 直 接 new 一 个 真实 角色 ， 如 代码 清单 12-16 所 示 。 


代码 清单 12-16 直接 访问 真实 角色 


public class Client { 

public static void main(String[|] args) { 
// 定 义 一 个 游戏 的 角 
IGamePlayer player = new GamePlayer(" 张 三"); 
// 开 始 打 游戏 ， 记 下 时 间 改 
System.out.println(" 开 始 时 间 是 : 2009-8-25 10:45"); 
player .login("zhangSan", "password"); 
// 开 始 杀 怪 
player .killBoss(); 
// 升 级 
player .upgrade( )， 
// 记 录 结 束 游戏 时 间 
System.out.println(" 结 束 时 间 是 : 2009-8-26 03:40"); 


令 

















想 想 看 能 运行 吗 ? 运行 结果 如 下 所 示 : 


开始 时 间 是 : 2009-8-25 10:45 














请 使 用 指定 的 代理 访问 

















请 使 用 指定 的 代理 访问 























请 使 用 指定 的 代理 访问 





结束 时 间 是 : 2009-8-26 03:40 








它 要 求 你 必须 通过 代理 来 访问 ， 你 想 要 直接 访问 它 ， 门 儿 都 没有 ， 
好 ， 你 要 我 通过 代理 来 访问 ， 那 就 生产 一 个 代理 ， 如 代码 清单 12-17 所 





钞 。 


代码 清单 12-17 直接 访问 代理 类 


public class Client { 

public static void main(String[] args) { 
// 定 义 一 个 游戏 的 角 
IGamePlayer player = new GamePlayer(" 张 三"); 
// 然 后 再 定义 一 个 代 练 者 
IGamePlayer proxy = new GamePlayerProxy(player); 
// 开 始 打 游戏 ， 记 下 时 间 堆 
System.out.println(" 开 始 时 间 是 : 2009-8-25 10:45"); 
proxy.1login("zhangSan", "password"); 
// 开 始 杀 怪 
proxy.killBoss(); 
// 升 级 
proxy.upgrade( )， 
// 记 录 结 束 游戏 时 间 
System.out.println(" 结 束 时 间 是 : 2009-8-26 03:40"); 


Ey 


























这 次 能 访问 吗 ? 还 是 不 行 ， 结 果 如 下 所 示 : 


开始 时 间 是 : 2009-8-25 10:45 














请 使 用 指定 的 代理 访问 

















请 使 用 指定 的 代理 访问 























请 使 用 指定 的 代理 访问 





结束 时 间 是 : 2009-8-26 03:40 





还 是 不 能 访问 ， 为 什么 呢 ? 它 不 是 真实 角色 指定 的 对 象 ， 这 个 代理 
对 象 是 你 自己 new 出 来 的 ， 当 然 真 实 对 象 不 认 了 ， 这 束 好 比 是 那个 明 
星 ， 人 家 已 经 告诉 你 去 找 她 的 代理 人 了 ， 你 随便 找 个 代理 人 能 成 吗 ? 你 
必须 去 找 她 指定 的 代理 才 成 ! 我 们 修改 一 下 场景 类 ， 如 代码 清单 12-18 
所 示 。 


代码 清单 12-18 强制 代理 的 场景 类 


public class Client { 

public static void main(String[] args) { 
// 定 义 一 个 游戏 的 角色 
IGamePlayer player = new GamePlayer(" 张 三 "); 
// 获 得 指定 的 代理 
IGamePlayer proxy = player.getProxy(); 
// 开 始 打 游戏 ， 记 下 时 间 改 
System.out.println(" 开 始 时 间 是 : 2009-8-25 10:45"); 
proxy.1login("zhangSan", "password"); 
// 开 始 杀 怪 
proxy.killBoss(); 
// 升 级 
proxy.upgrade( )， 
// 记 录 结 束 游戏 时 间 
System,out.println(" 结 束 时 间 是 : 2009-8-26 03:;40"); 























运行 结果 如 下 : 


开始 时 间 是 : 2009-8-25 10:45 





登录 名 为 zhangSan 的 用 户 张 三 登 录 成 功 ! 
张 三 在 打 怪 ! 
张 三 又 升 了 一 级 ! 


结束 时 间 是 : 2009-8-26 03:40 





OK， 可 以 正常 访问 代理 了 。 强 制 代理 的 概念 束 是 要 从 真实 角色 查 
找到 代理 角色 ， 不 允许 直接 访问 真实 角色 。 高 层 模 块 只 要 调用 getProxy 
就 可 以 访问 真实 角色 的 所 有 方法 ， 它 根本 就 不 需要 产生 一 个 代理 出 来 ， 
代理 的 管理 已 经 由 真实 角色 自己 完成 。 








12.4.3 代理 是 有 个 性 的 





一 个 类 可 以 实现 多 个 接口 ， 完 成 不 同 任务 的 整合 。 也 就 是 说 代理 类 
不 仅仅 可 以 实现 主题 接口 ， 也 可 以 实现 其 他 接口 完成 不 同 的 任务 ， 而 且 
代理 的 目的 是 在 目标 对 象 方法 的 基础 上 作 增 强 ， 这 种 增强 的 本 质 通 常 就 
是 对 目标 对 象 的 方法 进行 拦截 和 过 滤 。 例 如 游戏 代理 是 需要 收费 的 ， 升 
一 级 需要 5 元 钱 ， 这 个 计算 功能 束 是 代理 类 的 个 性 ， 它 应 该 在 代理 的 接 


<<interface>> 
ICamePlayer 
= 
togin(String user, String password) 
+void kilBoss() 
+void uperade() 














口中 定义 ， 如 图 12-6 所 示 。 








<<imnterface>> 
IProxy 
一 一 下 


+vold count() 





图 12-6 代理 类 的 个 性 


增加 了 一 个 IProxy 接 口 ， 其 作用 是 计算 代理 的 费用 。 我 们 先 来 看 
IProxy 接 口 ， 如 代码 清单 12-19 所 示 。 


代码 清单 12-19 代理 类 的 接口 


public interface IProxy { 
// 计 算 费 用 


public void count(); 


仅仅 一 个 方法 ， 非 营 简 单 ， 看 GamePlayerProxy 带 来 的 变化 ， 如 代 
码 清单 12-20 所 示 。 


代码 清单 12-20 代理 类 


public class GamePlayerProxy implements IGamePlayer,IProxy { 
private IGamePlayer gamePlayer = null; 
// 通 过 构造 函数 传递 要 对 谁 进行 代 练 
public GamePlayerProxy(IGamePlayer _gamePlayer)t{ 
this.gamePlayer = _gamePlayer; 














} 

// 代 练 杀 怪 

public void killBoss() { 
this.gamePlayer .killBoss(); 


} 

// 代 练 登录 

public void login(String user, String password) { 
this.gamePlayer.1login(user, password); 


} 

// 代 练 升级 

public void upgrade() { 
this.gamePlayer .upgrade( ); 
this.count(); 


3 

// 计 算 费 用 

public void count()t{ 
System.out.println(" 升 级 总 费用 是 : 150 元 " ) ; 

} 








实现 了 IProxy 接 口 ， 同 时 在 upgrade 方 法 中 调用 该 方法 ， 完 成 费用 结 
算 ， 其 他 的 类 都 没有 任何 改动 ， 运 行 结果 如 下 : 





开始 时 间 是 : 2009-8-25 10:45 








登录 名 为 zhangSan 的 用 户 张 三 登 录 成 功 ! 
张 三 在 打 怪 ! 
张 三 又 升 了 一 级 ! 


升级 总 费用 是 : 150 元 





结束 时 间 是 : 2009-8-26 03:40 


好 了 ， 代 理 公 司 也 赚钱 了 ， 我 的 游戏 也 升级 了 ， 和 彰 大 欢喜 。 代 理 关 
不 仅仅 是 可 以 有 上 自己 的 运算 方法 ， 通 常 的 情况 下 代理 的 职责 并 不 一 定单 
一 ， 它 可 以 组 合 其 他 的 真实 角色 ， 也 可 以 实现 自己 的 职责 ， 比 如 计算 费 
用 。 代 理 类 可 以 为 真实 角色 预 处 理 消 轧 、 过 滤 消 轧 、 消 息 转发 、 事 后 处 
理 消息 等 功能 。 当 然 一 个 代理 类 ， 可 以 代理 多 个 真实 角色 ， 并 且 真 实 角 
色 之 间 可 以 有 耦合 关系 ， 读 者 可 以 自行 扩展 一 下 。 








124 4 动人 在 代理 


放 在 最 后 讲 的 一 般 都 是 压轴 大 戏 ， 动 态 代理 就 是 如 此 ， 上 面 的 章节 
都 是 一 个 引子 ， 动 态 代理 才 是 重头 戏 。 什 么 是 动态 代理 ? 动态 代理 是 在 
实现 阶段 不 用 关心 代理 谁 ， 而 在 运行 阶段 才 指定 代理 哪 一 个 对 象 。 相 对 
来 说 ， 自 己 写 代理 类 的 方式 就 是 静态 代理 。 本 章节 的 核心 部 分 就 在 动态 
代理 上 ， 现 在 有 一 个 非常 流行 的 名 称 叫做 面向 横 切 面 编程 ， 也 就 是 
AOP (Aspect Oriented Programming) ， 其 核心 就 是 采用 了 动态 代理 机 
制 ， 既 然 这 么 重要 ， 我 们 就 来 看 看 动态 代理 是 如 何 实现 的 ， 还 是 以 打 游 











戏 为 例 ， 类 图 修改 一 下 以 实现 动态 代理 ， 如 图 12-7 所 示 。 


<<interface>> <<interface>> 
InvocationHandler IGame Player 
[| 


+void login(String user, String password) 





+void kilBoss() 
+vold upgrade() 









GamePlayer 






Game PlayIH 
| 
ed 





图 12-7 动态 代理 


在 类 图 中 增加 了 一 个 InvocationHandler 接 口 和 GamePlayIH 类 ， 作 用 
就 是 产生 一 个 对 象 的 代理 对 象 ， 其 中 mvocationHandler 是 JDK 提 供 的 动 
态 代理 接口 ， 对 被 代理 类 的 方法 进行 代理 。 我 们 来 看 程序 ， 接 口 保持 不 
变 ， 实 现 类 也 没有 变化 ， 请 参考 代码 清单 12-1 和 代码 清单 12-2 所 示 。 我 


们 来 看 DynamicProxy 类 ， 如 代码 清单 12-21 所 示 。 


代码 清单 12-21 动态 代理 类 


public class GamePlayIH implements InvocationHandler { 
// 被 代理 者 
Class cls =null; 
// 被 代理 的 实例 




















Object obj = null; 

// 我 要 代理 谁 

public GamePlayIH(Object _obj)t{ 
this.obj = _obj; 


} 
// 调 用 被 代理 的 方法 
public Object invoke(Object proxy, Method method, Object[] a 
throws Throwable { 
Object result = method.invoke(this.obj, args); 
return result,; 















































其 中 invoke 方 法 是 接口 InvocationHandler 定 义 必须 实现 的 ， 它 

对 真实 方法 的 调用 。 我 们 来 详细 讲解 一 下 InvocationHandler 接 口 ， 动 态 
代理 是 根据 被 代理 的 接口 生成 所 有 的 方法 ， 也 就 是 说 给 定 一 个 接口 ， 动 
态 代理 会 宣称 “我 已 经 实现 该 接口 下 的 所 有 方法 了 ”， 那 各 位 读者 想 想 

看 ， 动 态 代理 怎么 才能 实现 被 代理 接口 中 的 方法 呢 ? 默认 情况 下 所 有 的 
方法 返回 值 都 是 空 的 ， 是 的 ， 代 理 已 经 实现 它 了 ， 但 是 没有 任何 的 逻辑 
含义 ， 那 怎么 办 ? 好 办 ， 通 过 InvocationHandler 接 口 ， 所 有 方法 都 由 该 
Handler 来 进行 处 理 ， 即 所 有 被 代理 的 方法 都 由 InvocationHandler 接 管 实 
际 的 处 理 任 务 。 











我 们 接 下 来 看 看 场景 类 ， 如 代码 清单 12-22 所 示 。 


代码 清单 12-22 动态 代理 的 场景 类 


public class Client { 
public static void main(String[|] args) throws Throwable { 
// 定 义 一 个 痢 迷 的 玩家 
IGamePlayer player = new GamePlayer(" 张 三"); 
// 定 义 一 个 handler 
InvocationHandler handler = new GamePlayIH(player ) ， 
// 开 始 打 游戏 ， 记 下 时 间 堆 





System.out.println(" 开 始 时 间 是 : 2009-8-25 10:45"); 

// 获 得 类 的 class loader 

ClassLoader cl = player.getcClass().getClassLoader(); 
// 动 态 产生 一 个 代理 者 

IGamePlayer proxy = (IGamePlayer)Proxy.newProxyInsta 
// 登 录 

proxy.1login("zhangSan", "password"); 

// 开 始 杀 怪 

proxy.killBoss(); 

// 升 级 

proxy.upgrade( )， 

// 记 录 结 束 游戏 时 间 

System.out.println(" 结 束 时 间 是 : 2009-8-26 03:40"); 
































很 奇怪 是 吗 ? 不 要 着 急 ， 继 续 看 下 去 。 其 运行 结果 如 下 : 


开始 时 间 是 : 2009-8-25 10:45 








登录 名 为 zhangSan 的 用 户 张 三 登 录 成 功 ! 
张 三 在 打 怪 ! 
张 三 又 升 了 一 级 ! 


结束 时 间 是 : 2009-8-26 03:40 





我 们 还 是 让 代 练 者 帮 我 们 打 游 戏 ， 但 是 我 们 既 没有 创建 代理 类 ， 也 
没有 实现 IGamePlayer 接 口 ， 这 就 是 动态 代理 。 别 急 ， 动 态 代 理 可 不 仪 
仅 束 这 么 多 内 容 ， 还 有 更 重要 的 ， 如 果 想 让 游戏 登录 后 及 一 个 信息 给 我 
们 ， 防 止 账号 被 人 盗用 嘛 ， 该 怎么 处 理 ? 直接 修改 被 代理 类 
GamePlayer? 这 不 是 一 个 好 办 法 ， 好 办 法 如 代码 清单 12-23 所 示 。 


代码 清单 12-23 修正 后 的 动态 代理 


public class GamePlayIH implements InvocationHandler { 











// 被 代理 者 

Class cls =null; 

// 被 代理 的 实例 

Object obj = null; 

// 我 要 代理 谁 

public GamePlayIH(Object _obj)t{ 
this.obj] = _obj; 



























































} 
// 调 用 被 代理 的 方法 
public Object invoke(Object proxy, Method method, Object[] a 
throws Throwable { 
Object result = method.invoke(this.obj, args); 
// 如 果 是 登录 方法 ， 则 发 送信 息 
if(method.getName().equalsIgnoreCase("login"))t{ 
System.out.println(" 有 人 在 用 我 的 账号 登录 ! ")， 
} 


return result,; 











只 要 在 代理 中 增加 一 个 判断 就 可 以 决定 是 否 要 发 送信 息 ， 运 行 结果 
如 下 : 


开始 时 间 是 : 2009-8-25 10:45 





登录 名 为 zhangSan 的 用 户 ” 张 三 登录 成 功 ! 





有 人 在 用 我 的 账号 登录 ! 





张 三 在 打 怪 ! 
张 三 又 升 了 一 级 ! 


结束 时 间 是 : 2009-8-26 03:40 








太 棒 了 ! 有 人 用 我 的 账号 就 发 送 一 个 信息 ， 然 后 看 看 自己 的 账号 是 
不 是 被 人 次 了， 非常 好 的 方法 ， 这 就 是 AOP 编 程 。AOP 编 程 没 有 使 用 什 
么 新 的 技术 ， 但 是 它 对 我 们 的 设计 、 编 码 有 非常 大 的 影响 ， 对 于 日 志 、 
事务 、 权 限 等 都 可 以 在 系统 设计 阶段 不 用 考虑 ， 而 在 设计 后 通过 AOP 的 





方式 切 过 去 。 既 然 动 态 代理 是 如 此 诱 人 ， 我 们 来 看 看 通用 动态 代理 模 
型 ， 类 图 如 图 12-8 所 示 。 


DynamicProxy Client 
<<mterface>> <<interface>> 
InvocationHandler Subject 
一 
[一 
Hvoid exec() 


j 置 前 知 bso V MylInvo er 
一 一 一 一 一 一 | | 


图 12-8 动态 代理 通用 类 图 











<<Interface>> 


IAdvice 























很 简单 ， 两 条 独立 发 展 的 线路 。 动 态 代 理 实现 代理 的 职责 ， 业 务 逻 
辑 Subject 实 现 相 关 的 逻辑 功能 ， 两 者 之 间 没 有 必然 的 相互 耦合 的 关系 。 
通知 Advice 从 另 一 个 切面 切入 ， 最 终 在 高 层 模块 也 就 是 Client 进 行 耦 
合 ， 完 成 逻辑 的 封闭 任务 。 我 们 先 来 看 Subject 接 口 ， 如 代码 清 蛙 12-24 
所 示 。 


代码 清单 12-24 抽象 主题 


public interface Subject { 
// 业 务 操作 
public void doSomething(String str); 


其 中 的 doSomething 是 一 种 标识 方法 ， 可 以 有 多 个 逻辑 处 理 方法 ， 
实现 类 如 代码 清单 12-25 所 示 。 


代码 清单 12-25 真实 主题 


public class RealSubject implements Subject { 
// 业 务 操作 
public void doSomething(String str) { 
System.out.println("do something!---->" + str); 
} 


重点 是 我 们 的 MyInvocationHandler， 如 代码 清单 12-26 所 示 。 


代码 清单 12-26 动态 代理 的 Handler 类 


public class MyInvocationHandler implements InvocationHandler { 
// 被 代理 的 对 象 
private Object target = null; 
// 通 过 构造 函数 传递 一 个 对 象 
public MyInvocationHandler(Object _obj)t{ 
this.target = _obj; 









































} 
// 代 理 方 法 
public Object invoke(Object proxy, Method method, Object[] a 
throws Throwable { 
// 执 行 被 代理 的 方法 


return method.invoke(this.target, args); 























非常 简单 ， 所 有 通过 动态 代理 实现 的 方法 全 部 通过 invoke 方 法 调 
用 。DynamicProxy 代 码 如 代码 清单 12-27 所 示 。 


代码 清单 12-27 动态 代理 类 


public class DynamicProxy<T> { 


public static <T> T newProxyInstance(ClassLoader loader, Cla 
// 寻 找 JoinPoint 连 接点 ，AOP 框 架 使 用 元 数据 定义 
if(true)t{ 
// 执 行 一 个 前 置 通知 
(new BeforeAdvice()),exec() ， 


了 
// 执 行 目标 ， 并 返回 结果 


return (T)Proxy.newProxyInstance(loader,interfaces, 











在 这 里 插入 了 较 多 的 AOP 术 语 ， 如 在 什么 地 方 ( 连 接点 ) 执行 什么 

行为 《通知 ) 。 我 们 在 这 里 实现 了 一 个 简单 的 横 切 面 编程 ， 有 经 验 的 读 

者 可 以 看 看 AOP 的 配置 文件 就 会 明白 这 段 代码 的 意义 了 。 我 们 来 看 通知 
Advice， 也 就 是 我 们 要 切入 的 类 ， 接 口 和 实现 如 代码 清单 12-28 所 示 。 





代码 清单 12-28 通知 接口 及 实现 


public interface IAdvice { 
// 通 知 只 有 一 个 方法 ， 执 行 即 可 
public void exec( ) ， 











public class BeforeAdvice implements IAdvicet 
public void exec(){ 
System.out.println(" 我 是 前 置 通知 ， 我 被 执行 了 !"); 
} 


最 后 就 是 看 我 们 怎么 调用 了 ， 如 代码 清单 12-29 所 示 。 


代码 清单 12-29 动态 代理 的 场景 类 


public class Client { 
public static void main(String[|] args) { 
// 定 义 一 个 主题 
Subject subject = new RealSubject(); 
// 定 义 一 个 Handler 
InvocationHandler handler = new MyInvocationHandler( 























// 定 义 主题 的 代理 
Subject proxy = DynamicProxy.newProxyInstance(subjec 

getClassLoader(), subject.getClass().getIinterfaces 
// 代 理 的 行为 


proxy.doSsomething("Finish"); 




















-一 


运行 结果 如 下 所 示 : 


我 是 前 置 通知 ， 我 被 执行 了 ! 





do something!---->Finish 








好 ， 所 有 的 程序 都 看 完了 ， 我 们 回 过 头 来 看 看 程序 是 怎么 实现 的 。 
在 DynamicProxy 类 中 ， 我 们 有 这 样 的 方法 : 


this.obj=Proxy.newProxyInstance(c.getClassLoader(),c.getInterfaces(),new 


MYyInvocationHandler(_obj)); 


该 方法 是 重新 生成 了 一 个 对 象 ， 为 什么 要 重新 生成 ? 你 要 使 用 代理 
呀 ， 注 意 c.getInterfaces() 这 句 话 ， 这 是 非常 有 意思 的 一 句 话 ， 是 说 查找 
到 该 类 的 所 有 接口 ， 然 后 实现 接口 的 所 有 方法 。 当 然 了 ， 方 法 都 是 空 
的 ， 由 谁 具体 负责 接管 呢 ? 是 new MyInvocationHandler(_Obj) 这 个 对 
象 。 于 是 我 们 知道 一 个 类 的 动态 代理 类 是 这 样 的 一 个 类 ， 由 
InvocationHandler 的 实现 类 实现 所 有 的 方法 ， 由 其 invoke 方 法 接管 所 有 
方法 的 实现 ， 其 动态 调用 过 程 如 图 12-9 所 示 。 








Client DynamicProxy MYyInvocationHandler Subject 对 象 


doSomethineg() invoke() “invoke()™ 
一 一 一 一 一 -一 





图 12-9 动态 代理 调用 过 程 示 意图 


读者 可 能 注意 到 我 们 以 上 的 代码 还 有 更 进一步 的 扩展 余地 ， 注 意 看 
DynamicProxy 类 ， 它 是 一 个 通用 类 ， 不 具有 业务 意义 ， 如 果 我 们 再 产生 
一 个 实现 类 是 不 是 就 很 有 意义 了 呢 ? 如 代码 清单 12-30 所 示 。 








代码 清单 12-30 具体 业务 的 动态 代理 


public class SubjectDynamicProxy extends DynamicProxyt 
public static <T> T newProxyInstance(Subject subject)t{ 

// 获 得 ClassLoader 
ClassLoader loader = Subject.getClass().getClassLoad 
// 获 得 接口 数组 
Class<?>[] classes = subject.getClass().getIinterface 
// 获 得 handler 
InvocationHandler handler = new MyInvocationHandler( 
return newProxyInstance(loader, classes, handler); 


如 此 扩展 以 后 ， 高 层 模块 对 代理 的 访问 会 更 加 简单 ， 如 代码 清单 
12-31 所 示 。 


代码 清单 12-31 场景 类 


public class Client { 


public static void main(String[] args) { 
// 定 义 一 个 主题 
Subject subject = new RealSubject( ) ; 

















// 定 义 主题 的 代理 
Subject proxy = SubjectDynamicProxy ,newProxyInstance 
// 代 理 的 行为 
proxy.doSsomething("Finish"); 
} 
} 
是 不 是 更 加 简单 了 ? 可 能 读者 就 要 提问 了 ， 这 样 与 静态 代理 还 有 什 
么 区 别 ? 都 是 需要 实现 一 个 代理 类 ， 有 区 别 ， 注 意 看 父 类 ， 动 态 代 理 的 





主要 意图 就 是 解决 我 们 利 说 的 “审计 ”问题 ， 也 就 是 模 切 面 编程 ， 在 不 改 
变 我 们 已 有 代码 结构 的 情况 下 增强 或 控制 对 象 的 行为 。 








注意 ”要 实现 动态 代理 的 首要 条 件 是 : 被 代理 类 必须 实现 一 个 接 
口 ， 回 想 一 下 前 面 的 分 析 吧 。 当 然 了 ， 现 在 也 有 很 多 技术 如 CGLIB 可 以 
实现 不 需要 接口 也 可 以 实现 动态 代理 的 方式 。 











12.5 最 佳 实践 


代理 模式 应 用 得 非常 广泛 ， 大 到 一 个 系统 框架 、 企 业 平台 ， 小 到 代 
码 片 段 、 事 务 处 理 ， 稍 不 留意 就 用 到 代理 模式 。 可 能 该 模式 是 大 家 接触 
最 多 的 模式 ， 而 且 有 了 AOP 大 家 写 代 理 束 更 加 简单 了 ， 有 类 似 Spring 
AOP 和 Aspect 这 样 非常 优秀 的 工具 ， 拿 来 主义 即 可 ! 不 过 ， 大 家 可 以 看 
看 源 代 码 ， 特 别 是 调试 时 ， 只 要 看 到 类 似 $Proxy0 这 样 的 结构 ， 你 就 应 


该 知道 这 是 一 个 动态 代理 了 。 








友情 提醒 ， 在 学 习 AOP 框 架 时 ， 弄 清楚 几 个 名 词 就 成 : 切面 
(Aspect) 、 切 入 点 (JoinPoint) 、 通 知 (Advice) 、 织 入 〈Weave) 
就 足够 了 ， 理 解 了 这 几 个 名 词 ， 应 用 时 你 就 可 以 游 思 有余 了 ! 


第 13 章 ”原型 模式 


13.1 个 性 化 电子 账单 


现在 电子 账单 越 来 越 流 行 了 ， 比 如 你 的 信用 卡 ， 每 到 月 初 的 时 候 银 
行 就 会 发 一 份 电子 邮件 给 你 ， 说 你 这 个 月 消费 了 多 少 ， 什 么 时 候 消费 
的 ， 积 分 是 多 少 等 ， 这 是 每 个 月 发 一 次 。 还 有 一 种 也 是 银行 发 的 邮件 你 

定 非 常 有 印象 : 广告 信 ， 现 在 各 大 银行 的 信用 卡 部 门 都 在 拉拢 客户 ， 
电子 邮件 是 一 种 廉价 、 快 捷 的 通信 方式 ， 你 用 纸 质 的 广告 信 那 个 费用 多 
高 呀 ， 比 如 我 行 今天 推出 一 个 信用 卡 刷 卡 抽 奖 活动 ， 通 过 电子 账单 系统 
可 以 一 个 晚上 发 送 给 600 万 客户 ， 为 什么 要 用 电子 账单 系统 呢 ? 直接 找 
个 发 垃圾 邮件 的 工具 不 就 解决 问题 了 吗 ? 是 个 好 主意 ， 但 是 这 个 方案 在 
金融 行业 是 行 不 通 的 ， 为 什么 ? 因为 银行 发 送 该 类 邮件 是 有 要 求 的 : 

















个 性 化 服务 


一 般 银 行 都 要 求 个 性 化 服务 ， 发 过 去 的 邮件 上 总 有 一 些 个 人 信息 
吧 ， 比如 “xx 先生 ” “xx 女士 ”等 。 


e@ 递送 成 功率 


邮件 的 递送 成 功率 有 一 定 的 要 求 ， 由 于 大 批量 地 发 送 邮件 会 被 接收 


方 邮件 服务 右 误 认 是 垃圾 邮件 ， 因 此 在 邮件 头 和 要 增加 一 些 伪造 数据 ， 以 
规避 被 反 垃 圾 邮件 引擎 误 认 为 是 垃圾 邮件 。 


从 这 两 方面 考虑 广告 信和 的 发 送 也 是 电子 账单 系统 (电子 账单 系统 一 
般 包 括 : 账单 分 析 、 账 单 生 成 器 、 广 告 信 管理 、 发 送 队 列 管理 、 发 送 
机 、 退 信 处 理 、 报 表 管 理 等 ) 的 一 个 子 功 能 ， 我 们 今天 就 来 考虑 一 下 广 
告 信 这 个 模块 是 怎么 开发 的 。 那 既然 是 广告 信 ， 肯 定 需要 一 个 模板 ， 然 
后 再 从 数据 库 中 把 客户 的 信息 一 个 一 个 地 取出 ， 放 到 模板 中 生成 一 份 完 
整 的 邮件 ， 然 后 扔 给 发 送 机 进行 友 送 处 理 ， 类 图 如 图 13-1 所 示 。 








在 类 图 中 AdvTemplate 是 广告 信 的 模板 ， 一 般 都 是 从 数据 库 取出 ， 
生成 一 个 BO 或 者 是 DTO， 我 们 这 里 使 用 一 个 静态 的 值 来 作 代 表 ; Mail 
类 是 一 封 邮件 类 ， 友 送 机 发 送 的 就 是 这 个 类 。 我 们 先 来 看 
AdvTemplate， 如 代码 清单 13-1 所 示 。 


AdvTemplate 


-String receiver -String advSubject = "™ 
-String subject -Strmg advContext 一” 


Se +String getAdvSubjectO 
de +Strng getAdvContext() 
-String tall 


HMaill(AdvTemplate advTemplate) 
tgetter/setter() 








图 13-1 发 送 电子 账单 类 图 


代码 清单 13-1 广告 信 模 板 代 码 


public class AdvTemplate { 
// 广 告 信和 名 称 
private String advSubject ="XXx 银 行 国庆 信用 卡 抽奖 活动 "， 
// 广 告 信和 内容 
private String advContext = "国庆 抽奖 活动 通知 : 只 要 刷卡 就 送 你 一 百 天 
// 取 得 广告 信 的 名 称 
public String getAdvSubject(){ 
return this.advSubject; 


} 

// 取 得 广告 信 的 内 容 

public String getAdvContext(){ 
return this.advContext,; 

} 























邮件 类 Mail 如 代码 清单 13-2 所 示 。 


代码 清单 13-2 邮件 类 代码 


public class Mail { 

// 收 件 人 

private String receiver; 

// 邮 件 名 称 

private String subject; 

// 称 谓 

private String appellation; 

// 邮 件 内 容 

private String contxt; 

// 邮 件 的 尾部 ， 一 般 都 是 加 上 "XXX 版 权 所 有 "等 信息 

private String tail; 

// 构 造 函数 

public Mail(AdvTemplate advTemplate)t{ 
this.contxt = advTemplate.getAdvContext( ); 
this.subject = advTemplate.getAdvSubject( ); 











} 

// 以 下 为 getter/setter 方 法 

public String getReceiver() { 
return receiver,; 


} 
public 
} 
public 
} 
public 
} 
public 
} 
public 
} 
public 
} 
public 
} 
public 


} 
public 
} 


void setReceiver(String receiver) { 


this.receiver = receiver; 


String getSubject() { 
return subject,; 


void setSubject(String subject) { 


this.subject = subject; 


String getAppellation() { 
return appellation; 


void setAppellation(String appellation) { 
this.appellation = appellation; 


String getContxt() { 
return contxt,; 


void SetContxt(String contxt) { 
this.contxt = contxt; 


String getTail() { 
return tail; 


void setTail(String tail) { 
this.tail = tail; 


Mail 类 就 是 一 个 业务 对 象 ， 虽 然 比 较 长 ， 
来 看 业务 场景 类 是 如 何 对 邮件 继续 处 理 的 ， 如 代码 清单 11-3 所 示 。 


代码 清单 13-3 场景 类 


public class Client { 


// 发 送 账单 的 数量 ， 这 个 值 是 从 数据 库 中 获得 








private static int MAX _ COUNT = 6; 
public static void main(String[] args) { 


// 模 拟 发 送 邮件 


int i=0; 


// 把 模板 定义 出 来 ， 这 个 是 从 数据 库 中 获得 





还 是 比较 简单 的 。 我 们 再 





Mail mail = new Mail(new AdvTemplate()); 





mail.setTail( "XX 银行 版 权 所 有 "); 





. 


while(i<MAX COUNT){ 
// 以 下 是 每 封 邮 件 不 同 的 地 方 
mail.setAppellation(getRandString(5)+" 先生 
mail.setReceiver(getRandString(5)+"@"+getR 


// 然 后 发 送 邮 件 
sendMail(mail); 
工 + 十 ， 
} 
} 
// 发 送 邮件 


public static void sendMail(Mail mail){ 
System.out.printLn(" 标 题 : "+mail.getSubject() + "Nt 收 1 
"+mail.,getReceiver()+"\t,, ,发 送 成 功 ! ") ) 


} 
// 获 得 指定 长 度 的 随机 字符 串 
public static String getRandString(int maxLength)t{ 
String source ="abcdefghijklmnopqrskuvwxyzABCDEFGHIJ 
StringBuffer sb = new StringBuffer(); 
Random rand = new Random( ) ; 
for(int i=0;i<maxLength;i++){ 
sb.append(source.charAt(rand.nextInt(source. 


























pe sb.tostring(); 

} 

运行 结果 如 下 所 示 : 
标题 ，XX 银 行 国庆 信用 卡 收 件 人 : .… 发 送 成 
抽奖 活动 fjQUm@ZnkyPSsL.com 功 ! 
标题 ，XX 银 行 国庆 信用 卡 收 件 人 : .… 发 送 成 
抽奖 活动 ZIKnCONOKdloNM.com 功 ! 
标题 ，XX 银 行 国庆 信用 卡 收 件 人 : .… 发 送 成 
抽奖 活动 zNkMI@HpMMSZaz.com Dy 
标题 ，XX 银 行 国庆 信用 卡 收 件 人 : .… 发 送 成 
抽奖 活动 oMTFA@uBwkRjxa.com 功 ! 
标题 ，XX 银 行 国庆 信用 卡 收 件 人 : .… 发 送 成 
抽奖 活动 TquWT@TLLVNFja.com 功 ! 
标题 ，XX 银 行 国庆 信用 卡 收 件 人 : .… 发 送 成 


抽奖 活动 rkQbp@mfATHDQH.com 功 ! 





由 于 是 随机 数 ， 每 次 运行 都 有 所 差异 ， 不 管 怎 么 样 ， 我 们 这 个 电子 
账单 发 送 程序 是 编写 出 来 了 ， 也 能 正 币 发 送 。 我 们 再 来 仔细 地 想 想 ， 
个 程序 是 个 有 问题 ? Look here， 这 征 一 个 线程 在 运行 ， 也 就 是 你 发 送 的 
征 单线 程 的 ， 那 按照 一 封 邮件 发 出 去 需要 0.02 秒 〈 够 小 了 ， 你 还 要 到 数 
据 库 中 取 数 据 呢 ) ，600 万 封 邮件 需要 33 个 小 时 ， 也 就 是 一 个 整 天 都 发 
送 不 完 ， 今 天 的 没 发 送 完 ， 明 天 的 账单 又 产生 了 ， 上 日积月累， 激 起 甲 方 
人 员 一 扒 抱 怨 ， 那 怎么 办 ? 














好 办 ， 把 sendMail 修 改 为 多 线程 ， 但 是 只 把 sendMail 修 改 为 多 线程 
还 是 有 问题 的 呀 ， 产 生 第 一 封 邮件 对 象 ， 放 到 线程 1 中 运行 ， 还 没有 发 
送出 去 ;线程 2 也 启动 了 ， 直 接 就 把 邮件 对 象 mail 的 收 件 人 地 址 和 称谓 
修改 掉 了 ， 线 程 不 安全 了 。 说 到 这 里 ， 你 会 说 这 有 N 多 种 解决 办 法 ， 其 
中 一 种 是 使 用 一 种 新 型 模式 来 解决 这 个 问题 : 通过 对 象 的 复制 功能 来 解 
决 这 个 问题 ， 类 图 稍 做 修改 ， 如 图 13-2 所 示 。 





<<mterface>> 
Cloneable 








AdvTemplate 


-String receiver 
-String subject 


-Strng appellation | De 
.String contxt +Strng getAdvSubject() 


-String tail +Strng getAdvContext() 


+Mall(AdvTemplate advTemplate) 
tMail clone() 
+getter/setter() 


-String advSubject = 
-String advContext = " 









图 13-2 修改 后 的 发 送 电子 账单 类 图 


增加 了 一 个 Cloneable 接 口 (Java 自 带 的 一 个 接口 ) ， Mail 实 现 了 这 
个 接口 ， 在 Mail 类 中 禾 写 clone0 方 法 ， 我 们 来 看 Mail 类 的 改变 ， 如 代码 
清单 13-4 所 示 。 


代码 清单 13-4 修改 后 的 邮件 类 


public class Mail implements Cloneable{ 
// 收 件 人 
private String receiver; 
// 邮 件 名 称 
private String subject; 
// 称 谓 
private String appellation,; 
// 邮 件 内 容 
private String contxt; 


// 邮 件 的 尾部 ， 一 般 都 是 加 上 "XXX 版 权 所 有 "等 信息 

private String tail; 

// 构 造 函数 

public Mail(AdvTemplate advTemplate)t{ 
this.contxt = advTemplate.getAdvContext(); 
this.subject = advTemplate.getAdvSubject( ) ; 








@Override 
public Mail clone(){ 
Mail mail =null; 
try { 
mail = (Mail)super.clone(); 
} catch (CloneNotSupportedException e) { 
// TODO Auto-generated catch block 
e.printStackTrace( ); 


有 


return mail; 





} 

// 以 下 为 getter/setter 方 法 

public String getReceiver() { 
return receiver,; 


public void setReceiver(String receiver) { 
this.receiver = receiver; 


public String getSubject() { 
return subject; 


public void setSubject(String subject) { 
this.subject = subject; 


} 
public String getAppellation() { 
return appellation; 


public void setAppellation(String appellation) { 
this.appellation = appellation; 


public String getContxt() { 
return Contxt ， 


public void setContxt(String contxt) { 
this.contxt = contxt; 


} 
public String getTail() { 
return tail; 


public void setTail(String tail) { 
this.tail = tail; 


我 们 再 来 看 场景 Client 的 变化 ， 如 代码 清单 13-5 所 示 。 


代码 清单 13-5 修改 后 的 场景 类 


public class Client { 
// 发 送 账单 的 数量 ， 这 个 但 是 从 数据 库 中 获得 
private static int MAX_COUNT = 6; 
public static void main(String[] args) { 
// 模 拟 发 送 邮 件 
int i=0; 
// 把 模板 定义 出 来 ， 这 个 是 从 数据 中 获得 
Mail mail = new Mail(new AdvTemplate( )); 
mail.setTail("XX 银 行 版 权 所 有 "); 
while(i<MAX COUNT){ 
// 以 下 是 每 封 邮 件 不 同 的 地 方 
Mail cloneMail = mail.clone(); 
cloneMail.setAppellation(getRandString(5)+" 处 
cloneMail.setReceiver(getRandString(5)+"@"+ge 
// 然 后 发 送 邮件 
sendMail(cloneMail); 
i++; 














运行 结果 不 变 ， 一 样 完 成 了 电子 广告 信 的 发 送 功能 ， 而 且 sendMail 
即使 是 多 线程 也 没有 关系 。 注 意 ， 看 Client 类 中 的 粗 体 字 mailLclone0) 这 
个 方法 ， 把 对 象 复制 一 份 ， 产 生 一 个 新 的 对 象 ， 和 原 有 对 象 一 样 ， 然 后 
再 修改 细节 的 数据 ， 如 设置 称谓 、 设 置 收 件 人 地 址 等 。 这 种 不 通过 new 
关键 字 来 产生 一 个 对 象 ， 而 是 通过 对 象 复制 来 实现 的 模式 就 叫做 原型 模 
二 








13.2 原型 模式 的 定义 


原型 模式 (Prototype Pattern) 的 简单 程度 仅 次 于 单 例 模式 和 迭 代 堪 


模式 。 正 是 由 于 简单 ， 使 用 的 场景 才 非 常 地 多 ， 其 定义 如 下 : 


Specify the kinds of objects to create using a prototypical instance,and 


create new objects by copying this prototype.《〈 用 原型 实例 指定 创建 对 象 的 


种 类 ， 并 且 通 过 找 贝 这 些 原型 创建 新 的 对 象 。 ) 


原型 模式 的 通用 类 图 如 图 13-3 所 示 。 








Client +prototype 







Prototype 


+clone() 


ConcretePrototype 


图 13-3 原型 模式 的 通用 类 图 


简单 ， 太 简单 了 ! 原型 模式 的 核心 是 一 个 clone 方 法 ， 通 过 该 方法 进 
行 对 象 的 拷贝 ，Java 提 供 了 一 个 Cloneable 接 口 来 标示 这 个 对 象 是 可 拷贝 
的 ， 为 什么 说 是 “标示 ” 呢 ? 翻 开 JDK 的 帮助 看 看 Cloneable 是 一 个 方法 都 
没有 的 ， 这 个 接口 只 是 一 个 标记 作用 ， 在 JVM 中 具有 这 个 标记 的 对 象 才 
有 可 能 被 拷贝 。 那 怎么 才能 从 “有 可 能 被 拷贝 "转换 为 “可 以 被 拷贝 * 呢 ? 
方法 是 窗 盖 clone() 方 法 ， 是 的 ， 你 没有 看 错 是 重 写 clone() 方 法 ， 看 看 我 
们 上 面 Mail 类 中 的 clone 方 法 ， 如 代码 清单 13-6 所 示 。 





代码 清单 13-6 邮件 类 中 的 done 方 法 


@Override 
public Mail clone(){} 


注意 ， 在 clone() 方 法 上 增加 了 一 个 注解 @Override， 没 有 继承 一 个 
类 为 什么 可 以 宪 写 呢 ? 想 想 看， 在 Java 中 所 有 类 的 老 祖宗 是 谁 ” 对 呆 ， 
Object 类 ， 每 个 类 默认 都 是 继承 了 这 个 类 ， 所 以 用 敢 与 是 非常 正确 的 
一 一 履 写 了 Object 类 中 的 Clone 方法 ! 


在 Java 中 原型 模式 是 如 此 简单 ， 我 们 来 看 通用 源 代码 ， 如 代码 清单 


13-7 所 示 O 


代码 清单 13-7 原型 模式 通用 源码 


public class PrototypeClass implements Cloneablef{ 
// 履 写 父 类 0bject 方 法 
@Override 
public PrototypeClass clone(){ 
PrototypeClass prototypeClass = null; 


try { 





prototypeClass = (PrototypeClass)super.clonel( 
} catch (CloneNotSupportedException e) { 

// 异 常 处 理 
} 


return prototypeClass; 























实现 一 个 接口 ， 然 后 重 写 clone 方 法 ， 就 完成 了 原型 模式 ! 


13.3 原型 模式 的 应 用 


13.3.1 原型 模式 的 优点 


e 性 能 优 展 





原型 模式 是 在 内 存 二 进 制 流 的 拷贝 ， 要 比 直 接 new 一 个 对 象 性 能 好 
很 多 ， 特 别 是 要 在 一 个 循环 体内 产生 大 量 的 对 象 时 ， 原 型 模式 可 以 更 好 
地 体现 其 优点 。 





e 逃避 构造 函数 的 约束 


这 既是 它 的 优点 也 是 缺点 ， 直 接 在 内 存 中 拷贝 ,构造 函数 是 不 会 执 
行 的 “参见 13.4 节 ) 。 优 点 束 是 减少 了 约束 ， 缺 点 也 是 减少 了 约束 ， 需 
要 大 家 在 实际 应 用 时 考虑 。 


13.3.2 原型 模式 的 使 用 场景 


e 资源 优化 场景 


类 初始 化 需要 消化 非常 多 的 资源 ， 这 个 资源 包括 数据 、 人 硬件 资源 


四 
等 。 


e 性 能 和 安全 要 求 的 场景 








通过 new 产 生 一 个 对 象 需要 非常 党 琐 的 数据 准备 或 访问 权限 ， 则 可 
以 使 用 原型 模式 。 


e 一 个 对 象 多 个 修改 者 的 场景 


一 个 对 象 斋 要 提供 给 其 他 对 象 访 问 ， 而 且 各 个 调用 者 可 能 都 需要 修 
改 其 值 时 ， 可 以 考虑 使 用 原型 模式 拷贝 多 个 对 象 供 调用 者 使 用 。 








在 实际 项 目 中 ， 原 型 模式 很 少 单独 出 现 ， 一 般 是 和 工厂 方法 模式 一 
起 出 现 ， 通 过 clone 的 方法 创建 一 个 对 象 ， 然 后 由 工厂 方法 提供 给 调用 
者 。 原 型 模式 已 经 与 Java 融 为 一 体 ， 大 家 可 以 随手 拿 来 使 用 。 





13.4 原型 模式 的 注意 事项 


原型 模式 虽然 很 简单 ， 但 是 在 Java 中 使 用 原型 模式 也 就 是 clone 方 法 
是 有 一 些 注意 事项 的 ， 我 们 通过 几 个 例子 逐个 解说 。 


13.4.1 构造 函数 不 会 被 执行 





一 个 实现 了 Cloneable 并 重 写 了 clone 方 法 的 类 A， 有 一 个 无 参 构造 或 
有 参 构 造 B， 通 过 new 关 键 字 产生 了 一 个 对 象 S， 再 然后 通过 S$.clone() 方 
式 产 生 了 一 个 新 的 对 象 T[， 那 么 在 对 象 拷贝 时 构造 函数 B 是 不 会 被 执行 
的 。 我 们 来 写 一 小 段 程序 来 说 明 这 个 问题 ， 如 代码 清单 13-8 所 示 。 


代码 清单 13-8 简单 的 可 拷贝 对 象 


public class Thing implements Cloneablet{ 
public Thing(){ 
System.out.printLn(" 构 造 函 数 被 执行 了 . .."); 


Qoverride 
public Thing clone(){ 
Thing thing=null; 
try { 
thing = (Thing)super.clonel(); 
} catch (CloneNotSupportedException e) { 
e.printStackTrace( ); 


return thing; 


然后 我 们 再 来 写 一 个 Client 类 ， 进 行 对 象 的 拷贝 ， 如 代码 清单 13-9 
所 示 。 


代码 清单 13-9 简单 的 场景 类 


public class Client { 
public static void main(String[] args) { 
// 产 生 一 个 对 象 
Thing thing = new Thing(); 
// 找 贝 一 个 对 象 
Thing cloneThing = thing.clone(); 


ww 


运行 结 末 如 下 所 示 : 
构造 函数 被 执行 了 .… 


对 象 拷贝 时 构造 函数 确实 没有 被 执行 ， 这 点 从 原理 来 讲 也 是 可 以 讲 
得 通 的 ，Object 类 的 dlone 方 法 的 原理 是 从 内 存 中 (具体 地 说 就 是 堆 内 
存 ) 以 二 进 制 流 的 方式 进行 拷贝 ， 重新 分 配 一 个 内 存 块 ， 那 构造 函数 没 
有 被 执行 也 是 非常 正常 的 了 。 


13.4.2 浅 找 由 和 深 搁 由 


在 解释 什么 是 浅 拷 贝 和 什么 是 深 堵 贝 之 前 ， 我 们 先 来 看 个 例子 ， 如 
代码 清单 13-10 所 示 。 


代码 清单 13-10 浅 拷贝 


public class Thing implements Cloneablet{ 
// 定 义 一 个 私有 变量 
private ArrayList<String> arrayList = new ArrayList<String>( 
@Override 
public Thing clone(){ 
Thing thing=null; 
try { 
thing = (Thing)super.clone(); 
} catch (CloneNotSupportedException e) { 
e.printStackTrace( ) ; 











return thing; 
} 
// 设 置 HashMap 的 值 
public void setValue(String value)t{ 
this.arrayList.add(value); 
} 
// 取 得 arrayList 的 值 


public ArrayList<String> getValue(){ 
return this.arrayList; 
} 


在 Thing 类 中 增加 一 个 私有 变量 arrayLis， 类 型 为 ArrayList， 然 后 通 
过 setValue 和 getValue 分 别 进行 设置 和 取 值 ， 我 们 来 看 场景 类 是 如 何 拷贝 
的 ， 如 代码 清单 13-11 所 示 。 





代码 清单 13-11 浅 拷贝 测试 


public class Client { 

public static void main(String[|] args) { 
// 产 生 一 个 对 象 
Thing thing = new Thing(); 
// 设 置 一 个 值 
thing.setValue(" 张 三 ");} 
// 找 贝 一 个 对 象 
Thing cloneThing = thing.clone( ); 
cloneThing .setValue(" 李 四 ")， 
System.out.println(thing.getValue( )); 


猜想 一 下 运行 结果 应 该 是 什么 ? 是 仅 一 个 “ 张 三 ? 吗 ? 运行 结果 如 下 


所 示 : 
[ 张 三 ， 李 四 ] 


怎么 会 这 样 昵 ?怎么 会 有 李 四 呢 ?是 因为 Java 做 了 一 个 偷懒 的 拷贝 
动作 ，Object 类 提供 的 方法 clone 只 是 拷贝 本 对 象 ， 其 对 象 内 部 的 数组 、 
引用 对 象 等 都 不 拷贝 ， 还 是 指向 原生 对 象 的 内 部 元 素 地 址 ， 这 种 拷贝 就 
叫做 浅 拷贝 。 确 实 是 非常 浅 ， 两 个 对 象 共享 了 一 个 私有 变量 ， 你 改 我 改 
大 家 都 能 改 ， 是 一 种 非常 不 安全 的 方式 ， 在 实际 项 目 中 使 用 还 是 比较 少 
的 (当然 ， 这 也 是 一 种 “危机 ”环境 的 一 种 救命 方式 ) 。 你 可 能 会 比较 奇 
怪 ， 为 什么 在 Mail 那 个 类 中 就 可 以 使 用 String 类 型 ， 而 不 会 产生 由 浅 拷 
贝 带 来 的 问题 昵 ?” 内 部 的 数组 和 引用 对 象 才 不 拷贝 ， 其 他 的 原始 类 型 比 
如 int、long、char 等 都 会 被 拷贝 ， 但 是 对 于 String 类 型 ，Java 就 希望 你 把 
它 认 为 是 基本 类 型 ， 它 是 没有 clone 方 法 的 ， 处 理 机 制 也 比较 特殊 ， 通 过 
字符 串 池 〈stringpool) 在 需要 的 时 候 才 在 内 存 中 创建 新 的 字符 串 ， 读 者 
在 使 用 的 时 候 就 把 String 当 做 基本 类 使 用 即 可 。 

















注意 “使 用 原型 模式 时 ， 引 用 的 成 员 变 量 必须 满足 两 个 条 件 才 不 
会 被 拷贝 : 一 是 类 的 成 员 变 量 ， 而 不 是 方法 内 变量 ， 二 是 必须 是 一 个 可 
变 的 引用 对 象 ， 而 不 是 一 个 原始 类 型 或 不 可 变 对 象 。 














浅 拷贝 是 有 风险 的 ， 那 怎么 才能 深入 地 拷贝 呢 ? 我 们 修改 一 下 程序 
就 可 以 深 找 贝 ， 如 代码 清单 13-12 所 示 。 


代码 清单 13-12 深 拷贝 


public class Thing implements Cloneablet{ 
// 定 义 一 个 私有 变量 
private ArrayList<String> arrayList = new ArrayList<String>( 
Q@Override 
public Thing clone(){ 
Thing thing=null; 
try { 








thing = (Thing)super.clone(); 

thing.arrayList = (ArrayList<String>)this.arr 
} catch (CloneNotSupportedException e) { 

e.printStackTrace( ); 


return thing; 


运行 结果 如 下 所 示 : 


[ 张 三 ] 





该 方法 就 实现 了 完全 的 拷贝 ， 两 个 对 象 之 间 没 有 任何 的 瓜 蝎 了 ， 你 
修改 你 的 ， 我 修改 我 的 ， 不 相互 影响 ， 这 种 拷贝 就 叫做 深 捞 贝 。 深 搁 贝 
还 有 一 种 实现 方式 就 是 通过 自己 写 二 进 制 流 来 操作 对 象 ， 然 后 实现 对 象 
的 深 找 贝 ， 这 个 大 家 有 时 间 目 己 实现 一 下 。 























注意 深 捞 贝 和 浅 找 贝 建议 不 要 混合 使 用 ， 特 别 是 在 涉及 类 的 继 
承 时 ， 父 类 有 多 个 引用 的 情况 束 非 常 复杂 ， 建 议 的 方案 是 深 找 贝 和 浅 找 


贝 分 开 实现 。 





13.4.3 clone 与 final 两 个 多 家 





对 象 的 clone 与 对 象 内 的 final 关 键 字 是 有 冲突 的 ， 我 们 举例 来 说 明 这 
个 问题 ， 如 代码 清单 13-13 所 示 。 


代码 清单 13-13 增加 final 关 键 字 的 拷贝 


public class Thing implements Cloneablet{ 
// 定 义 一 个 私有 变量 
private final ArrayList<String> arrayList = new ArrayList<St 
@Override 
public Thing clone(){ 
Thing thing=null; 
try { 








thing = (Thing)super.clonel(); 

this.arrayList = (ArrayList<String>)this,arra 
} catch (CloneNotSupportedException e) { 

e.printStackTrace( ); 


return thing; 


仅仅 增加 了 一 个 final 关 键 字 ， 然 后 编译 器 就 报 斜体 部 分 错误 ， 正 常 
呀 ，final 类 型 你 还 想 重 赋值 呀 ! 你 要 实现 深 拷贝 的 梦想 在 final 关 键 字 的 
威胁 下 破灭 了 ， 路 总 是 有 的 ， 我 们 来 想 想 怎么 修改 这 个 方法 : 删除 掉 
final 关 键 字 ， 这 是 最 便捷 、 安 全 、 人 快速 的 方式 。 你 要 使 用 clone 方 法 ， 在 
类 的 成 员 变 量 上 就 不 要 增加 final 关 键 字 。 

















注意 ”要 使 用 cdlone 方 法 ， 类 的 成 员 变 量 上 不 要 增加 final 关 键 字 。 





13.5 最 佳 实践 





原型 模式 先 产 生出 一 个 包含 大 量 共有 信息 的 类 ， 然 后 可 以 拷贝 出 副 
本 ， 修 正 细 市 信息 ， 建 立 了 一 个 完整 的 个 性 对 象 。 不 知道 大 家 有 没有 看 
过 施 瓦 壮 格 沉 的 《第 六 日 》 这 部 电影 ， 电 影 的 主线 也 就 是 一 个 人 被 复 
制 ， 然 后 正本 和 副本 对 招 。 我 们 今天 讲 的 原型 模式 也 就 是 由 一 个 正本 可 
以 创建 多 个 副本 的 概念 。 可 以 这 样 理解 : 一 个 对 象 的 产生 可 以 不 由 零 起 
步 ， 直 接 从 一 个 已 经 具备 一 定 骏 形 的 对 象 元 隆 ， 然 后 再 修改 为 生产 需要 
的 对 象 。 也 残 是 说 ， 产 生 一 个 人 ， 可 以 不 从 1 岁 长 到 2 岁 ， 再 到 3 岁 .……. 
也 可 以 直接 找 一 个 人 ， 从 其 身上 获得 DNA， 然 后 克隆 一 个 ， 直 接 修改 一 
下 就 是 30 岁 了 ! 我 们 讲 的 原型 模式 也 就 是 这 样 的 功能 。 
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14.1 进 销 存 管理 是 这 个 样子 的 吗 





大 家 都 来 目 五 湖 四 海 ， 部 要 生存 ， 于 古都 找 了 个 徘 山 一 一 公司 ， 右 
古 给 你 发 薪水 的 地 方 。 公 司 要 想 尽 办 法 启 利 赚钱 ， 启 利 方法 则 不 尽 相 
同 ， 但 是 各 个 公司 都 有 相同 的 三 个 环节 : 采购 、 销 售 和 库存 。 这 个 怎么 
癌 呢 ? 比如 一 个 软件 公司 ， 要 开发 软件 ， 就 需要 购买 开 有 环境， 如 
Windows 操 作 系 统 、 数 据 库 产品 等 ， 这 就 是 采购 ;开发 完 产 品 还 要 把 产 
品 推销 出 去 ;， 有 产品 束 必 然 有 库存 ， 软 件 产 品 也 有 库存 ， 虽 然 不 需要 占 
用 库房 空间 ， 但 也 要 占用 光盘 或 便 熏 ， 这 也 是 库存 。 再 比如 做 咨询 服务 
的 公司 ， 它 要 采购 什么 ? 采购 知识 ， 采 购 经 验 ， 这 是 这 类 企业 的 生存 之 
本 ， 销 售 的 也 是 知识 和 经 验 ， 库 存 同 样 是 知识 和 经 验 。 既 然 进 销 存 是 如 
此 重要 ， 我 们 今天 就 来 讲 讲 它 的 原理 和 设计 ， 我 相信 很 多 人 都 已 经 开发 
过 这 种 类 型 的 软件 ， 基 本 上 都 形成 了 固定 套路 ， 不 管 是 单机 版 还 是 网 络 
版 ， 一 般 的 做 法 都 是 通过 数据 库 来 完成 相关 产品 的 管理 ， 相 对 来 说 这 还 
古 比 较 简 单 的 项 目 ， 三 个 模块 的 示意 图 如 图 14-1 所 未 。 














采购 管理 销售 管理 


图 14-1 进 销 存 示 意图 


我 们 从 这 个 示意 图 上 可 以 看 出 ， 三 个 模块 是 相互 依赖 的 。 我 们 就 以 
一 个 终 问 销售 商 〈 以 服务 最 终 客 户 为 目标 的 企业 ， 比 如 茶 东 超市 、 茶 某 
商店 等 ) 为 例 ， 采 购 部 门 要 采购 IBM 的 电脑 ， 它 根据 以 下 两 个 要 素来 决 
定 采 购 数量 。 








销售 部 门 要 反馈 销售 情况 ， 有 畅销 束 多 采购 ， 清 销 就 不 采购 。 


e 库存 情况 








即使 是 畅销 产品 ， 库 存 都 有 1000 台 了， 每 天 才 卖 出 去 10 台 ， 也 就 不 
要 再 采购 了 ! 





销售 模块 是 企业 的 赢利 核心 ， 对 其 他 两 个 模块 也 有 影响 ; 


e 库存 情况 





库房 有 上 货 ， 才 能 销售 ， 空 手套 日 狼 是 不 行 的 。 


e 千 促 采购 


在 特殊 情况 下 ， 比 如 一 个 企业 客户 要 一 次 性 购买 100 台 电脑 ， 库 存 
只 有 80 台 ， 这 时 需要 催促 采购 部 门 赶 快 和 采购 ! 








同样 地 ， 库 存 管 理 也 对 其 他 两 个 模块 有 影响 。 库 房 是 有 容积 限制 
的 ， 不 可 能 无 限 大 ， 所 以 加 有 了 清仓 处 理 ， 那 就 要 求 采 购 部 门 停止 采 
购 ， 同 时 销售 部 门 进行 打折 销售 。 





从 以 上 分 析 来 看 ， 这 三 个 模块 都 有 目 己 的 行为 ， 并 且 与 其 他 模块 之 
间 的 行为 产生 关联 ， 类 似 于 我 们 办 公 室 的 同事 ， 大 家 各 干 各 的 活 ， 但 是 
彼此 之 间 还 是 有 交叉 的 ， 于 是 彼此 之 间 束 产生 紧 炎 合 ， 也 就 是 一 个 团 
队 。 我 们 先 来 实现 这 个 进 销 存 ， 类 图 如 图 14-2 所 示 。 





+void sellBMComputer(int number) 
+mt getSaleStatus() 
+void offSale() 


+void increase(int number) 
+vold decrease(Int number) 
+int getStockNumber() 
tvoid clearStock() 





图 14-2 简单 的 进 销 存 类 图 


Purchase 人 负责 采购 管理 ，buyIBMComputer 指 定 了 玉 购 IBM 电 脑 ， 
refuseBuyIBM 是 指 不 再 采购 IBM 了 ， 源 代码 如 代码 清单 14-1 所 示 。 


代码 清单 14-1 采购 管理 


public class Purchase { 
// 采 购 IBM 电 脑 
public void buyIBMcomputer(int number)t{ 
// 访 问 库存 
Stock stock = new Stock(); 
// 访 问 销售 
Sale sale = new Sale(); 
// 电 脑 的 销售 情况 
int saleStatus = sale.getSaleStatus(); 
if(saleStatus>80){f // 销 售 情况 良好 
System,out,println(" 采 购 IBM 电 脑 :"+number + "人 台 
stock.increase(number ) 
}else{ // 销 售 情况 不 好 
int buyNumber = number/2; // 折 半 采 购 
System,out.printlLn(" 采 购 IBM 电 脑 : "+buyNumber+ 














ber 











2. 
// 不 再 采购 IBM 电 脑 
public void refuseBuyIBM( ){ 
System.out .println(" 不 再 采购 IBM 电 脑 " ); 
} 


ww 


Purchase 定 义 了 采购 电脑 的 标准 : 如 果 销 售 情况 比较 好 ， 大 于 80 
分 ， 你 让 我 采购 多 少 我 就 采购 多 少 ， 销 售 情况 不 好 ， 你 让 我 采购 100 
台 ， 我 就 采购 50 台 ， 对 折 采 购 。 电 脑 采 购 完毕 ， 需 要 放 到 库房 中 ， 因 此 
要 调用 库存 的 方法 ， 增 加 库存 电脑 数量 。 我 们 继续 来 看 库房 Stock 类 ， 
如 代码 清单 14-2 所 示 。 








代码 清单 14-2 库存 管理 


public class Stock { 
// 刚 开始 有 100 台 电脑 
private static int COMPUTER_ NUMBER =100; 
// 库 存 增加 
public void increase(int number){ 
COMPUTER_NUMBER = COMPUTER_ NUMBER + number; 
System.out .println(" 库 存 数量 为 : "+COMPUTER_NUMBER ) ; 


} 

// 库 存 降低 

public void decrease(int number){ 
COMPUTER_NUMBER = COMPUTER_NUMBER - number; 
System,out,println(" 库 存 数 量 为 : "+COMPUTER_NUMBER ) ; 


} 

// 获 得 库存 数量 

public int getStockNumber(){ 
return COMPUTER_NUMBER; 


} 
// 存 货 压力 大 了 ， 就 要 通知 采购 人 员 不 要 采购 ， 销 售 人员 要 尽快 销售 
public void clearStock(){ 
Purchase purchase = new Purchase() ; 
Sale sale = new Sale(); 
System.out.println(" 清 理 存货 数量 为 : "+COMPUTER_NUMBER ); 
// 要 求 折 价 销 售 
sale.offSale( ); 
// 要 求 采 购 人 员 不 要 采购 
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purchase ,refuseBuyIBM( ) ; 





库房 中 的 货物 数量 肯定 有 增 减 ， 同 时 库房 还 有 一 个 容量 显示 ， 达 到 





一 定 的 容量 后 束 要 求 对 一 些 了 商品 进行 折价 处 理 ， 以 腾 出 更 多 的 空间 容纳 
新 产品 。 于 是 就 有 了 dlearStock 方 法 ， 既 然 是 清仓 处 理 肯 定 就 要 折价 销 








售 了 。 于 是 在 Sale 类 中 就 有 了 offSale 方 法 ， 我 们 来 看 Sale 源 代码 ， 如 代 


码 清 单 14-3 所 


小 。 


代码 清单 14-3 销售 管理 


public class 





Sale { 


// 销 售 IBM 电 脑 
public void sellIiBMComputer(int number)t{ 


System.out.p 





} 
// 反 馈 销 
public 


} 
// 折 价 处 理 


public 


// 访 问 库存 

Stock stock = new Stock(); 

// 访 问 采 购 

Purchase purchase = new Purchase(); 

if(stock,getStockNumber()<number){f // 库 存 数量 不 够 销售 
purchase.buyIBMcomputer (number ); 


Hr 











} 
rintln(" 销 售 ITBM 电 脑 "+number+" 台 ") ， 
stock.decrease(number ) 


售 情况 ，9 一 166 之 间 变化 ，9 代 表 根 本 就 没 人 卖 ，196 代 表 非 常 畅销 ， 出 
int getSaleStatus(){ 

Random rand = new Random(System.currentTimeMillis()) 
int saleStatus = rand.nextInt(100); 
System.out.println("IBM 电 脑 的 销售 情况 为 "+SaleStatus ) 
return saleStatus; 






































void offSale(){ 
// 库 房 有 多 少 卖 多 少 
Stock stock = new Stock(); 
System.out.println(" 折 价 销 售 IBM 电 脑 "+stock.getStockNum 








Sale 类 


中 了 。 记 住 要 把 恰当 的 类 放 到 恰当 的 类 中 ， 销 售 


反馈 出 来 ， 


中 的 getSaleStatus 是 获得 销售 情况 ， 这 个 当然 要 出 现在 Sale 类 








情况 只 有 销售 人 员 才 外 


CC 





过 百分制 的 机 制衡 量 销售 情况 。 我 们 再 来 看 场景 类 是 怎么 
运行 的 ， 场 景 类 如 代码 清单 14-4 所 示 。 


代码 清单 14-4 场景 类 


public class Client { 
public static void main(String[] args) { 
// 采 购 人 员 采 购 电脑 


System.out.printin("------ 采购 人 员 采 购 电脑 


Purchase purchase = new Purchase( ) ; 
purchase ,buyIBMcomputer(100) ; 


// 销 





售 人 员 销 
System.out.println("\n------ 肖 售 





售 电脑 


Sale sale = new Salel() 
sale.sellIBMComputer(1); 



































// 库 房管 理 人 员 
System.out.println("\n------ 
Stock stock = new Stock(); 
stock.clearStock( ); 








管理 库存 





























里 人 员 





售 电脑 - - - 

















清 库 处 天 








我 们 在 场景 类 中 模拟 了 三 种 人 员 的 活动 : 采购 人 员 采 购 电脑 ， 销 售 


人 员 销 售 电脑 ， 库 ; 


pan 员 答 





局 见 忆 


理 库存 。 





ee 采购 人 员 采 购 电 脑 -------- 


IBM 电 脑 的 销售 








天 








采购 IBMI 








电脑 :100 台 





库存 数量 为 : 200 


是 销售 人 员 销 售 








青 况 为 : 95 


电脑 -------- 


运行 结果 如 下 所 示 : 














销售 IBM 电 脑 1 台 





库存 数量 为 : 199 














二 库房 管理 人 员 清 库 处 理 ------- 





























清理 存货 数量 为 : 199 








折价 销售 IBM 电 脑 199 台 








不 再 采购 IBM 电 脑 


运行 结果 也 是 我 们 期 望 的 ， 三 个 不 同类 型 的 参与 者 完成 了 各 目的 活 
动 。 你 有 没有 发 现 这 三 个 类 是 彼此 关联 的 ? 每 个 类 都 与 其 他 两 个 类 产生 
了 关联 关系 。 迪 米 特 法 则 认为 “每 个 类 只 和 朋友 类 交流”， 这 个 朋友 类 并 
非 越 多 越 好 ， 朋 友 类 越 多 ， 和 耦合 性 越 大 ， 要 想 修改 一 个 就 得 修改 一 片 ， 
这 不 是 面 问 对 象 设 计 所 期 望 的 ， 况 且 这 还 是 仅 三 个 模块 的 情况 ， 属 于 比 
较 简 单 的 一 个 小 项 目 。 我 们 把 进 销 存 扩展 一 下 ， 如 图 14-3 所 示 。 








采购 





图 14-3 扩展 后 的 进 销 存 示 意图 





这 是 一 个 蜂 蛛 网 的 结构 ， 别 说 是 编写 程序 了 ， 束 是 给 人 看 估计 也 能 
让 一 大 批 人 昏倒 ! 每 个 对 象 都 需要 和 其 他 几 个 对 象 交 流 ， 对 象 越 多 ， 
个 对 象 要 交流 的 成 本 也 就 越 大 了 ， 只 是 维护 这 些 对 象 的 交流 残 能 让 一 大 
批 程序 员 望 而 却步 ! 从 这 方面 来 说 ， 我 们 已 经 发 现 设 计 的 缺陷 了 ， 作 为 
一 个 架构 师 ， 发 现 缺 陷 就 要 想 办 法 修改 。 





大 家 都 学 过 网 络 的 基本 知识 ， 网 络 拓扑 有 三 种 类 型 : 总 线 型 、 环 
型 、 星 型 。 星 型 网 络 拓扑 如 图 14-4 所 示 。 





在 星 型 网 络 拓扑 中 ， 每 个 计算 机 通过 交换 机 和 其 他 计算 机 进行 数据 
交换 ， 各 个 计算 机 之 间 并 没有 直接 出 现 区 互 的 情况 。 这 种 结构 简单 ， 而 
且 稳 定 ， 只 要 中 间 那 个 交换 机 不 瘫痪 ， 整 个 网 络 就 不 会 发 生 大 的 故障 。 
公司 和 网 吧 一 般 都 采用 星 型 网 络 。 我 们 是 不 是 可 以 把 这 种 星 型 结构 引入 
到 我 们 的 设计 中 呢 ? 我 们 先 画 一 个 示意 图 ， 如 图 14-5 所 示 。 


交换 机 


gs 
7 


图 14-4 星 型 网 络 拓扑 


图 14-5 修改 后 的 进 销 存 示 意图 


加 入 了 一 个 中 介 者 作为 三 个 模块 的 交流 核心 ， 每 个 模块 之 间 不 再 相 
互 交 流 ， 要 交流 就 通过 中 介 者 进行 。 每 个 模块 只 负责 自己 的 业务 馆 辑 ， 
不 属于 自己 的 则 丢 给 中 介 者 来 处 理 ， 简 化 了 各 模块 之 间 的 耦合 关系 ， 类 
图 如 图 14-6 所 示 。 








AbstractMediator 





#Purchase purchase 
#Sale sale 
+Stock stock 


+AbstractMediator() 
+void execute(String str, Object...objects) 


a 


Mediator 



















Purchase 


+void buyIBMcomputer(int number) 
+void refuseBuyIBM() 


+void execute(String str, Object...objects) +void selllBMComputer(int number) 
+int getSaleStatus() 


+void offSale() 

















| 








+vold increase(int number) 
+vold decrease(int number) 
+int getStockNumber() 
+void clearStock() 


AbstractColleague 
| #AbstractMediator mediator 





+AbstractColleague(AbstractMediator _mediator) 


图 14-6 修改 后 的 进 销 存 类 图 


建立 了 两 个 抽象 类 AbstractMediator 和 AbstractColeague， 每 个 对 象 
只 是 与 中 介 者 Mediator 之 间 产 生 依 赖 ， 与 其 他 对 象 之 间 没 有 直接 关系 ， 
AbstractMediator 的 作用 是 实现 中 介 者 的 抽象 定义 ， 定 义 了 一 个 抽象 方法 
execute， 如 代码 清单 14-5 所 示 。 


代码 清单 14-5 抽象 中 介 者 


public abstract class AbstractMediator { 
protected Purchase purchase; 
protected Sale sale; 
protected Stock stock; 
// 构 造 函数 
public AbstractMediator(){ 
purchase = new Purchase(this ) ， 


sale = new Sale(this); 
stock = new Stock(this); 


3 
// 中 介 者 最 重要 的 方法 叫做 事件 方法 ， 处 理 多 个 对 象 之 间 的 关系 


Te abstract void execute(String str,Object...objects); 
































再 来 看 具体 的 中 介 者 ， 我 们 可 以 根据 业务 的 要 求 产 生 多 个 中 介 者 ， 
并 划分 各 中 介 者 的 职责 。 有 具体 中 介 者 如 代码 清单 14-6 所 示 。 


代码 清单 14-6 具体 中 介 者 


public class Mediator extends AbstractMediator { 
// 中 介 者 最 重要 的 方法 
pb void execute(String str,Object...objects)t{ 
if(str.equals("purchase.buy")){ // 采 购 电 月 
this.buyComputer((Integer)objects[0]); 
}else if(str.equals("sale.sell")){ // 销 售 电脑 
this.sellComputer((Integer)objects[0]); 
}else if(str.equals("sale.offsell"))tf // 折 价 销售 
this.offSell( ); 
}else if(str.equals("stock.clear")){ // 清 仓 处 理 
this.clearStock( ); 
} 


} 
// 采 购 电脑 
private void buyComputer(int number){ 
int SaleStatus = super.sale.getSaleStatus(); 
if(saleStatus>80){ // 销 售 情况 良好 
System,out,println(" 采 购 IBM 电 脑 :"+number + " 台 " 
Super .stock.increase(number ) ; 
}elsef{f // 销 售 情 况 不 好 
int buyNumber = number/2; // 折 半 采 购 
System.out.println(" 采 采购 TBM 电 脑 : "+buyNumber+ " 
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9 
// 销 售 电脑 


private void sellComputer(int number)t{ 
if(super,stock.getStockNumber()<number){f // 库 存 数量 不 
super .purchase.buyIBMcomputer (number ); 








super.stock.decrease(number ) ; 


本 
// 折 价 销售 电脑 





private void offSell()t{ 
System,out.printlLn(" 折 价 销售 


Ut 





IBM 电 脑 "+stock.getStockNum 

















} 
// 清 仓 处 理 
private void clearStock()t{ 
// 要 求 清仓 销售 
super.sale.offSale( ); 
// 要 求 采购 人 员 不 要 采购 
Super ,purchase,refuseBuyIBM( ) ， 




















中 介 者 Mediator 定 义 了 多 个 private 方 法 ， 其 目的 是 处 理 各 个 对 象 之 
间 的 依赖 和 关系， 就 是 说 把 原 有 一 个 对 象 要 依赖 多 个 对 象 的 情况 移 到 中 介 
者 的 private 方 法 中 实现 。 在 实际 项 目 中 ， 一般 的 做 法 是 中 介 者 按照 职员 
进行 划分 ， 每 个 中 介 者 处 理 一 个 或 多 个 类 似 的 关联 请 求 。 








由 于 要 使 用 中 介 者 ， 我 们 增加 了 一 个 抽象 同事 类 ， 三 个 具体 的 实现 
类 分 别 继 承 该 抽象 类 ， 如 代码 清单 14-7 所 示 。 


代码 清单 14-7 抽象 同事 类 


public abstract class AbstractColleague { 
protected AbstractMediator mediator; 
public AbstractColleague(AbstractMediator _mediator)t{ 
this.mediator = _mediator; 
} 


采购 Purchase 类 如 代码 清单 14-8 所 示 。 


代码 清单 14-8 修改 后 的 采购 管理 


public class Purchase extends AbstractColleaguet 
public Purchase(AbstractMediator _mediator)t{ 
super(_mediator); 


} 
// 采 购 IBM 电 脑 
public void buyIBMcomputer(int number)t{ 
super .mediator.execute("purchase.buy", number); 


} 
// 不 再 采购 IBM 电 脑 
public void refuseBuyIBM(){ 
System.out .println(" 不 再 采购 IBM 电 脑 " ); 


上 述 Purchase 类 简化 了 很 多 ， 也 清晰 了 很 多 ， 人 处 理 上 自己 的 职责 ， 与 
外 界 有 关系 的 事件 处 理 则 交 给 了 中 介 者 来 完成 。 再 来 看 Stock 类 ， 如 代 
码 清单 14-9 所 示 。 


代码 清单 14-9 修改 后 的 库存 管理 


public class Stock extends AbstractColleague { 
public Stock(AbstractMediator _mediator)t{ 
super(_mediator); 


} 

// 刚 开始 有 100 台 电脑 

private static int COMPUTER_NUMBER =100; 

// 库 存 增加 

public void increase(int number)t{ 
COMPUTER_NUMBER = COMPUTER_NUMBER + number ， 
System.out,printJlIn(" 库 存 数量 为 : "+COMPUTER_NUMBER ) ， 


} 

// 库 存 降低 

public void decrease(int number){ 
COMPUTER_NUMBER = COMPUTER_NUMBER - number; 
System.out .println(" 库 存 数量 为 : "+COMPUTER_NUMBER ) ; 


} 

// 获 得 库存 数量 

public int getStockNumber (){ 
return COMPUTER_NUMBER ， 


} 
// 存 货 压力 大 了 ， 就 要 通知 采购 人 员 不 要 采购 ， 销 售 人 员 要 尽快 销售 
public void clearStock(){ 
System.out.println(" 清 理 存货 数量 为 : "+COMPUTER_NUMBER ) ; 
Super .mediator.execute("Sstock.clear'"); 
































Hr 























销售 管理 Sale 类 如 代码 清单 14-10 所 示 。 


代码 清单 14-10 修改 后 的 销售 管理 


public class Sale extends AbstractColleague { 
public Sale(AbstractMediator _mediator)t{ 
super(_mediator); 





} 

// 销 售 IBM 电 脑 

public void sellIiBMComputer(int number)t{ 
super .mediator.execute("sale.sell", number); 
System.out .println(" 销 售 IBM 电 脑 "+number+" 台 ")， 


} 

// 反 馈 销售 情况 ，0 一 100 变 化 ，9 代 表 根 本 就 没 人 买 ，1600 代 表 非 常 畅 销 ， 出 一 个 

public int getSaleStatus( ){ 
Random rand = new Random(System.currentTimeMillis()) 
int saleStatus = rand.nextInt(100); 
System.out.println("IBM 电 脑 的 销售 情况 为 ， "+saleStatus)，; 
return saleStatus; 


} 
// 折 价 处 理 
public void offSale(){ 

super .mediator.execute("sale.offsell"); 
} 









































增加 了 中 介 者 ， 场 景 类 也 需要 小 小 的 改动 ， 如 代码 清单 14-11 所 


代码 清单 14-11 修改 后 的 场景 类 


public class Client { 
public static void main(String[|] args) { 

AbstractMediator mediator = new Mediator(); 
// 采 购 人 员 采 购 电 脑 
System.out.println("------ 采购 人 员 采 购 电脑 -------- ys 
Purchase purchase = new Purchase(mediator ) ; 
purchase.buyIBMcomputer(100); 
// 销 售 人 员 销 售 电脑 











System,out.println("NXn------ 销售 人 员 销 售 


Sale sale = new Sale(mediator ) 
sale.sellIBMComputer(1); 
// 库 房管 理 人 员 管 理 库 存 
















































































System.out.printin("\n------ 库房 管理 





Stock stock = new Stock(mediator ) 
stock.clearStock( ); 





人 员 


清 库 处 理 -------. 





在 场景 类 中 增加 了 一 个 中 介 者 ， 然 后 分 别传 递 到 三 个 同事 类 中 ， 三 
类 都 具有 相同 的 特性 : 只 负责 处 理 自己 的 活动 (行为 ) ， 与 自己 无 关 
的 活动 就 丢 给 中 介 者 处 理 ， 程 序 运 行 的 结果 是 相同 的 。 从 项 目 设 计 上 来 





看 ， 加 入 了 中 介 者 ， 设 计 结构 清晰 了 很 多 ， 而 且 类 间 的 耦合 性 大 大 减 


少 ， 代 码 质量 也 有 了 很 大 的 提升 。 


在 多 个 对 象 依赖 的 情况 下 ， 通 过 加 入 中 介 者 角色 ， 取 消 了 多 个 对 象 


的 关联 或 依赖 关系 ， 减 少 了 对 象 的 耦合 性 。 


14.2 中 介 者 模式 的 定义 


中 介 者 模式 的 定义 为 : Define an object that encapsulates how a set of 
objects interact.Mediator promotes loose coupling by keeping objects from 
referring to each other explicitly,and it lets you vary their interaction 
independently.〈 用 一 个 中 介 对 象 封装 一 系列 的 对 象 交 互 ， 中 介 者 使 各 对 
象 不 需要 显示 地 相互 作用 ， 从 而 使 其 耘 合 松散 ， 而 且 可 以 独立 地 改变 它 
们 之 间 的 交互 。) 


中 介 者 模式 通用 类 图 如 图 14-7 所 示 。 









Mediator Colleague 






Concrete Mediator 


图 14-7 中 介 者 模式 通用 类 图 
从 类 图 中 看 ， 中 介 者 模式 由 以 下 几 部 分 组 成 : 
e Mediator 抽象 中 介 者 角色 
抽象 中 介 者 角色 定义 统一 的 接口 ， 用 于 各 同事 角色 之 间 的 通信 。 
e Concrete Mediator 具体 中 介 者 角色 


基体 中 介 者 角色 通过 协调 各 同事 角色 实现 协作 行为 ， 因 此 它 必 须 依 
赖 于 各 个 同事 角色 。 


e Colleague 同事 角色 


每 一 个 同事 角色 都 知道 中 介 者 角色 ， 而 且 与 其 他 的 同事 角色 通信 的 
时 候 ， 一 定 要 通过 中 介 者 角色 协作 。 每 个 同事 类 的 行为 分 为 两 种 : 一 种 
征 同事 本 身 的 行为 ， 比 如 改变 对 象 本 里 的 状态 ， 处 理 目 己 的 行为 等 ， 这 
种 行为 叫做 自发 行为 《Self-Method) ， 与 其 他 的 同事 类 或 中 介 者 没有 任 
何 的 依赖 ， 第 二 种 是 必须 依赖 中 介 者 才能 完成 的 行为 ， 叫 做 依赖 方法 
(Dep-Method) 。 





中 介 者 模式 比较 简单 ， 其 通用 源码 也 比较 简单 ， 先 看 抽象 中 介 者 
Mediator 类 ， 如 代码 清单 14-12 所 示 。 


代码 清单 14-12 通用 抽象 中 介 者 


public abstract class Mediator { 
// 定 义 同事 类 
protected ConcreteColleaguel ci1; 
protected ConcreteColleague2 c2; 
// 通 过 getter/setter 方 法 把 同事 类 注入 进来 
public ConcreteColleaguel1 getC1() { 
return CT， 














public void setCi(ConcreteColleaguel1 c1) { 
this.c1i = ci1; 


} 
public ConcreteColleague2 getC2() { 
return C2 ， 


} 
public void setC2(ConcreteColleague2 c2) { 
this.c2 = c2; 


} 

// 中 介 者 模式 的 业务 逻辑 
public abstract void doSomething1(); 
public abstract void doSomething2(); 





世 





在 Mediator 抽 象 类 中 我 们 只 定义 了 同事 类 的 注入 ， 为 什么 使 用 同事 
实现 类 注入 而 不 使 用 抽象 类 注入 呢 ? 那 是 因为 同事 类 虽然 有 抽象 ， 但 是 
没有 每 个 同事 类 必须 要 完成 的 业务 方法 ， 当 然 如 果 每 个 同事 类 都 有 相同 
的 方法 ， 比 如 execute、handler 等 ， 那 当然 注入 抽象 类 ， 做 到 依赖 倒置 。 








具体 的 中 介 者 一 般 只 有 一 个 ， 即 通用 中 介 者 ， 其 源 代码 如 代码 清单 


14-13 所 示 。 


代码 清单 14-13 通用 中 介 者 


public class ConcreteMediator extends Mediator { 
@Override 
public void doSomething1() { 
// 调 用 同事 类 的 方法 ， 只 要 是 public 方 法 都 可 以 调用 
super.c1.selfMethod1( ) ; 
super.c2.selfMethod2( ); 














public void doSomething2() { 
super.c1.selfMethod1( ) ; 
super.c2.selfMethod2(); 


中 介 者 所 具有 的 方法 doSomething1 和 doSomething2 都 是 比较 复杂 的 
业务 逻辑 ， 为 同事 类 服务 ， 其 实现 是 依赖 各 个 同事 类 来 完成 的 。 








同事 类 的 基 类 如 代码 清单 14-14 所 示 。 





代码 清单 14-14 抽象 同事 类 


public abstract class Colleague { 
protected Mediator mediator; 
public Colleague(Mediator _mediator){ 
this.mediator = _mediator; 
} 





这 个 基 类 也 非常 简单 。 一 般 来 说 ， 中 介 者 模式 中 的 抽象 都 比较 简 
单 ， 是 为 了 建 并 这 个 中 介 而 服务 的 ， 具 体 同事 类 如 代码 清单 14-15 所 


帮 \。 


代码 清单 14-15 具体 同事 类 


public class ConcreteColleaguel1 extends Colleague { 

// 通 过 构造 函数 传递 中 介 者 

public ConcreteColleaguei(Mediator _mediator)t{ 
super(_mediator); 








} 

// 自 有 方法 self-method 

public void selfMethod1()t{ 
// 处 理 自己 的 业务 逻辑 


} 
// 依 赖 方法 dep-method 
public void depMethod1(){ 






























































// 处 理 自己 的 业务 逻辑 
// 自 己 不 能 处 理 的 业务 逻辑 ， 委 托 给 中 介 者 处 理 
Super .mediator.doSomething1( ) ; 















































} 


public class ConcreteColleague2 extends Colleague { 
// 通 过 构造 函数 传递 中 介 者 
public ConcreteColleague2(Mediator _mediator)t{ 
super(_mediator); 








} 

// 自 有 方法 self-method 

public void selfMethod2(){ 
// 处 理 自己 的 业务 逻辑 


} 

// 依 赖 方法 dep-method 

public void depMethod2(){ 
// 处 理 自 己 的 业务 轴 辑 
// 自 己 不 能 处 理 的 业务 逻辑 ， 委 托 给 中 介 者 处 理 
super .mediator.doSomething2( ); 


































































































为 什么 同事 类 要 使 用 构造 函数 注入 中 介 者 ， 而 中 介 者 使 用 
getter/setter 方 式 注 入 同事 类 呢 ? 这 是 因为 同事 类 必须 有 中 介 者 ， 而 中 介 
者 却 可 以 只 有 部 分 同事 类 。 








14.3 中 介 者 模式 的 应 用 


14.3.1 中 介 者 模式 的 优点 


中 介 者 模式 的 优点 束 是 减少 类 间 的 依赖 ， 把 原 有 的 一 对 多 的 依赖 变 
成 了 一 对 一 的 依赖 ， 同 事 类 只 依赖 中 介 者 ， 减 少 了 依赖 ， 当 然 同时 也 降 
低 了 关 间 的 耦合 。 


14.3.2 中 介 者 模式 的 缺点 


中 介 者 模式 的 缺点 就 是 中 介 者 会 膨胀 得 很 大 ， 而 且 逻 辑 复 杂 ， 原 本 
N 个 对 象 和 直接 的 相互 依赖 关系 转换 为 中 介 者 和 同事 类 的 依赖 关系 ， 同 事 
类 越 多 ， 中 介 者 的 逻辑 就 越 复杂 。 


14.3.3 中 介 者 模式 的 使 用 场景 


中 介 者 模式 简单 ， 但 是 简单 不 代表 容易 使 用 ， 很 容易 被 误 用 。 在 面 
回 对 象 的 编程 中 ， 对 象 和 对 象 之 间 必 然 会 有 依赖 关系 ， 如 果 茶 个 类 和 其 
他 类 没有 任何 相互 依赖 的 关系 ， 那 这 个 类 就 是 一 个 “ 孤 怠 >， 在 项 目 中 就 
没有 存在 的 必要 了 1! 束 像 是 茶 个 人 如 果 永 远 独 立 生 活 ， 与 任何 人 都 没有 
关系 ， 那 这 个 人 基本 上 就 算是 野人 了 一 一 排除 在 人 类 这 个 定义 之 外 。 





类 之 间 的 依赖 关系 是 必然 存在 的 ， 一 个 类 依赖 多 个 类 的 情况 也 是 存 
在 的 ， 存 在 即 合理 ， 那 是 否 可 以 说 只 要 有 多 个 依赖 关系 束 考 虑 使 用 中 介 
者 模式 呢 ? 管 案 是 否定 的 。 中 介 者 模式 未 必 能 帮 你 把 原本 竣 乱 的 逻辑 整 
理 得 清 清楚 楚 ， 而 且 中 介 者 模式 也 是 有 缺点 的 ， 这 个 缺点 在 使 用 不 当时 
会 被 放大 ， 比 如 原本 束 简 单 的 几 个 对 象 依赖 关系， 如果 为 了 使 用 模式 而 
加 入 了 中 介 者 ， 必 然 导 致 中 介 者 的 逻辑 复杂 化 ， 因 此 中 介 者 模式 的 使 用 
需要 “量力 而 行 *! 中 介 者 模式 适用 于 多 个 对 象 之 间 紧 密 耘 合 的 情况 ， 紧 
密 厢 合 的 标准 是 ， 在 类 图 中 出 现 了 蜂 蛛 网 状 结构 。 在 这 种 情况 下 一 定 要 
考虑 使 用 中 介 者 模式 ， 这 有 利于 把 蜘蛛 网 梳理 为 星 型 结构 ， 使 原本 复杂 
混乱 的 关系 变 得 清晰 简单 。 











14.4 中 介 考 模式 的 实际 应 用 


中 介 者 模式 也 叫做 调停 者 模式 ， 是 什么 意思 呢 ? 一 个 对 象 要 和 N 多 
个 对 象 交 流 ， 就 像 对 象 间 的 战争 ， 很 混乱 。 这 时 ， 需 要 加 入 一 个 中 心 ， 
所 有 的 类 都 和 中 心 交 流 ， 中 心 说 怎么 处 理 就 怎么 处 理 ， 我 们 举 一 些 在 开 
发 和 生活 中 经 常会 碰 到 的 例子 。 





e 机 场 调度 中 心 


大 家 在 每 个 机 场 都 会 看 到 有 一 个 “xx 机 场 调度 中 心 "， 它 束 是 具体 的 
中 介 者 ， 用 来 调度 每 一 染 要 降落 和 起 飞 的 飞机 。 比 如 ， 茶 架 飞 机 (同事 
类 ) 飞 到 机 场 上 空 了 ， 束 询问 调度 中 心 〈 中 介 者 )“ 我 是 否 可 以 降落 ”以 
及 “降落 到 哪个 跑道 "， 调 度 中 心 〈 中 介 者 ) 但 看 其 他 飞机 (同事 类 ) 情 
况 ， 然 后 通知 飞机 降落 。 如 果 没 有 机 场 调度 中 心 ， 飞 机 飞 到 机 场 了 ， 飞 
行 员 要 先 看 看 有 没有 飞机 和 自己 一 起 降落 的 ， 有 没有 空 跑道 ， 停 机 位 是 
否 具 备 等 情况 ， 这 种 局 面 是 难以 想象 的 ! 








e MVC 框 架 


大 家 都 应 该 使 用 过 Struts，MVC 框 架 ， 其 中 的 C (Controller) 就 是 
一 个 中 介 者 ， 叫 做 前 端 控制 器 (Front Controlleam， 它 的 作用 融 是 把 
M(Model， 业 务 逻 辑 ) 和 V (View， 视 图 ) 隔离 开 ， 协 调 M 和 V 协 同 工 





作 ， 把 M 运 行 的 结果 和 V 代 表 的 视图 融合 成 一 个 前 器 可 以 展示 的 页 面 ， 
减少 M 和 V 的 依赖 关系 。MVC 框 架 已 经 成 为 一 个 非常 流行 、 成 熟 的 开发 
框架 ， 这 也 是 中 介 者 模式 的 优点 的 一 个 体现 。 


e 媒体 网 天 


媒体 网 关 也 是 一 个 典型 的 中 介 者 模式 ， 比 如 使 用 MSN 时 ， 张 三 发 消 
恩 给 李 四 ， 其 过 程 应 该 是 这 样 的 : 张 三 发 送 消 息 ，MSN 服 务 髓 (中 介 者 ) 
接收 到 消 妃 ， 碍 找 李 四 ， 把 消息 发 送 到 李 四 ， 同 时 通知 张 三 ， 消 息 已 经 
发 送 。 在 这 里 ，MSN 服 务 器 束 是 一 个 中 转 站 ， 负 责 协调 两 个 客户 端的 信 
息 交 流 ， 与 此 相反 的 就 是 IPMsg 〈 也 叫 飞 铝 ) ， 它 没有 使 用 中 介 者 ， 而 
直接 使 用 了 UDP 广播 的 方式 ， 每 个 客户 端 既是 客户 端 也 是 服务 需 端 。 














e 中 介 服 务 


现在 中 介 服 务 非常 多 ， 比 如 租房 中 介 、 出 国 中 介 ， 这 些 也 都 是 中 介 
模式 的 具体 体现 ， 比 如 你 去 租房 子 ， 如 宋 没有 房屋 中 介 ， 你 就 必须 一 个 
一 个 小 区 去 找 ， 看 看 有 没有 空房 子 ， 有 没有 适合 目 己 的 房子 ， 找 到 房子 
后 还 要 和 房东 签 合约 ， 上 自己 检查 房屋 的 家 具 、 水 电 煤 等 ， 有 了 中 介 后 ， 
你 就 省 心 多 了 ， 找 中 介 ， 然 后 安排 看 房子 ， 看 中 了 ， 符 合约， 中 介 帮 你 
检查 房屋 家 具 、 水 电 煤 等 等 。 这 也 是 中 介 模 式 的 实际 应 用 。 




















14.5 最 佳 实践 


本 章 讲 述 的 中 介 者 模式 很 少 用 到 接口 或 者 抽象 类 ， 这 与 依赖 倒置 原 
则 是 冲突 的 ， 这 是 什么 原因 呢 ? 首 先 ， 既 然 是 同事 类 而 不 是 兄 第 类 (有 
相同 的 血缘 ) ， 那 对 说 明 这些 类 之 间 是 协作 关系 ， 完 成 不 同 的 任务 ， 处 
理 不 同 的 业务 ， 所 以 不 能 在 抽象 类 或 接口 中 严格 定义 同事 类 必须 具有 的 
方法 〈 从 这 点 也 可 以 看 出 继承 是 高 侵入 性 的 ) 。 这 古 不 合适 的 ， 惑 像 你 
我 是 同事 ， 虽 然 我 们 大 家 都 是 朝 九 晚 五 地 上 班 ， 但 是 你 跟 我 干 的 活 肯 定 
不 同 ， 不 可 能 抽象 出 一 个 父 类 统一 定义 同事 所 必须 有 的 方法 。 当 然 ， 每 
个 同事 都 要 吃饭 、 上 厕所 ， 可 以 把 这 些 最 基本 的 信息 封装 到 抽象 中 ， 但 
这 些 最 基本 的 行为 或 属性 是 中 介 者 模式 要 关心 的 吗 ”如果 两 个 对 象 不 能 
提炼 出 共性 ， 那 就 不 要 刻意 去 奶 求 两 者 的 抽象 ， 抽 象 只 要 定义 出 模 陈 需 
要 的 角色 即 可 。 当 然 如 果 严 格 遵守 面 癌 接口 编程 的 话 ， 则 是 需要 抽象 
的 ， 这 就 再 要 读者 在 实际 开发 中 灵活 擎 握 。 其 次 ， 在 一 个 项 目 中 ， 中 介 
者 模式 可 能 被 多 个 模块 采用 ， 每 个 中 介 者 所 围绕 的 同事 类 各 不 相同 ， 你 
能 抽象 出 一 个 具有 共性 的 中 介 者 吗 ? 不 可 能 ， 一 个 中 介 者 抽象 类 一 般 只 
有 一 个 实现 者 ， 除 非 中 介 者 人 逻辑 非 党 复杂， 代码 量 非常 大 ， 这 时 才 会 出 
现 多 个 中 介 者 的 情况 。 所 以 ， 对 于 中 介 者 来 说 ， 抽 象 已 经 没有 太 多 的 必 


要 。 























中 介 者 模式 是 一 个 非常 好 的 封装 模式 ， 也 是 一 个 很 容易 被 滥用 的 模 





式 ， 一 个 对 象 依赖 几 个 对 象 是 再 正常 不 过 的 事情 ， 但 是 纯 理论 家 就 会 要 
求 使 用 中 介 者 模式 来 封装 这 种 依赖 关系 ， 这 是 非常 危险 的 ! 使 用 中 介 模 
式 就 必然 会 带 来 中 介 者 的 膨胀 问题 ， 这 在 一 个 项 目 中 是 很 不 恰当 的 。 大 
家 可 以 在 如 下 的 情况 下 尝试 使 用 中 介 者 模式 : 


e N 个 对 象 之 间 产 生 了 相互 的 依赖 关系 CN 之 2) 。 


e 多 个 对 月 有 依赖 和 关系， 但 是 依赖 的 行为 疝 不 确定 或 者 有 发 生 改 变 
的 可 能 ， 在 这 种 情况 下 一 般 建议 采用 中 介 者 模式 ， 降 低 变 更 引起 的 风险 
扩散 。 


e 产品 开 及 。 一 个 明显 的 例子 就 是 MVC 框 如 ， 把 中 介 者 模式 应 用 到 
产品 中 ， 可 以 提升 产品 的 性 能 和 扩展 性 ， 但 是 对 于 项 目 开 发 就 未 必 ， 
为 项 目 是 以 交付 投产 为 目标 ， 而 产品 则 是 以 稳定 、 高 效 、 扩 展 为 宗旨 。 

















第 15 章 ”命令 借 式 


15.1 项 目 经 理 也 难当 


我 是 公司 的 项 目 经 理 ， 在 国内 做 项 目 ， 项 目 经 理 需 要 什么 都 履 ， 什 
么 都 管 。 做 好 了 ， 项 目 经 理 能 分 到 一 杯 北 ;做 不 好 ， 都 是 项 目 经 理 的 贡 
任 。 这 几乎 是 绝对 的 ， 我 禹 过 很 多 项 目 ， 行 政 命 令 一 压 下 来 ， 那 就 一 条 
道 : 做 完 做 好 ! 





虽然 我 们 公司 是 一 个 集团 公司 ， 但 是 我 们 部 门 的 业绩 是 独立 核算 

的 ， 也 就 是 说 ， 我 们 部 门 不 仅 可 以 为 集团 公司 服务 ， 还 可 以 为 其 他 甲 方 
服务 ， 赚 取 更 多 的 外 快 。2007 年 ， 我 曾 负责 一 个 比较 小 的 项 目 《但 是 项 
目的 合同 金额 可 不 少 ) 一 一 为 和 家 旅行 社 建 立 一 套 内 部 省 理 系统 。 该 旅 
行 社 的 门店 比较 多 ， 员 工 也 比较 多 ， 这 个 内 部 管理 系统 用 来 管理 客户 、 
旅游 资源 、 票 务 以 及 内 部 事务 ， 整 体 上 类 似 于 一 个 小 型 的 MIS 系 统 。 客 
户 的 需求 比较 明确 ， 因 为 他 们 曾经 自己 购买 了 一 套 内 部 管理 系统 ， 这 次 
变动 基本 上 是 翻版 ， 而 且 这 家 旅行 社 也 有 目 己 的 IT 部 门 ， 技 术 人 员 之 间 
语言 相通 ， 比 较 好 相处 ， 也 没有 交流 鸿沟 。 








该 项 目的 成 员 分 工 采 用 了 第 规 的 分 工 方式 ， 分 为 需求 组 
(Requirement Group,RG) 、 美 工 组 (Page Group,PG) 、 代 码 组 〈 我 们 


内 部 还 有 一 个 比较 优雅 的 名 字 : 逻辑 实现 组 ， 这 里 使 用 大 家 经 常 称呼 的 
名 称 ， 即 Code Group， 简 称 CG) ， 加 上 我 这 个 项 目 经 理 正 好 十 个 人 。 

刚 开 始 ， 客 户 《 也 就 是 旅行 社 ， 甲 方 ) 很 乐意 和 我 们 每 个 组 探讨 ， 比 如 
和 需求 组 讨论 需求 、 和 美工 讨论 页 面 、 和 代码 组 讨论 实现 ， 告 诉 他 们 修 
改 、 删 除 、 增 加 各 种 内 容 等 。 这 是 一 种 比较 常见 的 甲乙 方 合作 模式 ， 甲 
方 深入 到 乙方 的 项 目 开 发 中 ， 我 们 可 以 使 用 类 图 来 表示 这 个 过 程 ， 如 图 


15-1 所 示 O 〇 


+void find() 
+void aad() 
+void delete() 
+void changel) 


tvoid plan() 





CodeGroup 





图 15-1 旅行 社 项 目 开 发 过 程 类 图 





这 个 类 图 很 简单 ， 客 户 和 三 个 组 都 有 交流 ， 这 也 合情合理 。 那 我 们 
看 看 这 个 过 程 的 实现 ， 首 先 看 抽象 类 Group， 如 代码 清单 15-1 所 示 。 


代码 清单 15-1 抽象 组 


public abstract class Group { 
// 甲 乙 双方 分 开办 公 ， 如 果 你 要 和 某 个 组 讨论 ， 你 首先 要 找到 这 个 组 
public abstract void find(); 
// 被 要 求 增 加 功能 
public abstract void add( ) ; 
// 被 要 求 删 除 功能 
public abstract void delete( ); 


// 被 要 求 修改 功能 








public abstract void change( ) ， 
// 被 要 求 给 出 所 有 的 变更 计划 


public abstract void plan(); 














大 家 看 抽象 类 中 的 每 个 方法 ， 其 中 的 每 个 都 是 一 个 命令 语气 
一 找到 它 ， 增 加 ， 删 除 ， 给 我 计划 1 ”这些 都 是 命令 ， 给 出 命令 然后 
由 相关 的 人 员 去 执行 。 我 们 再 看 3 个 实现 类 ， 其 中 的 需求 组 最 重要 ， 需 
求 组 RequirmentGroup 类 如 代码 清单 15-2 所 示 。 





代码 清单 15-2 需求 组 


public class RequirementGroup extends Group { 
// 客 户 要 求 需 求 组 过 去 和 他 们 谈 
public void find() { 
System.out ,println(" 找 到 需求 组 ,.,."); 


} 

// 客 户 要 求 增 加 一 项 需求 

public void add() { 
System.out.println(" 客 户 要 求 增加 一 项 需求 ..."); 


} 
// 客 户 要 求 修改 一 项 需求 
public void change() { 
System.out.println(" 客 户 要 求 修改 一 项 需求 . . ."); 


} 
// 客 户 要 求 删 除 一 项 需求 
public void delete() { 
System.out.println(" 客 户 要 求 删除 一 项 需求 .. ."); 


} 
// 客 户 要 求 给 出 变更 计划 
public void plan() { 
System.out.println(" 客 户 要 求 需求 变更 计划 ...")， 
} 









































需求 组 有 了 ， 我 们 再 看 美工 组 。 美 工 组 也 很 重要 ， 是 项 目的 脸面 ， 
客户 最 终 接触 到 的 还 是 界面 。 美 工 组 PageGroup 类 如 代码 清单 15-3 所 


代码 清单 15-3 美工 组 


public class PageGroup extends Group { 
// 首 先 这 个 美工 组 应 该 能 找到 吧 ， 要 不 你 跟 谁 谈 ? 
public void find() { 
System.out.println(" 找 到 美工 组 ..."); 


} 
// 美 工 被 要 求 增加 一 个 页 面 
public void add() { 























System.out.println(" 客 户 要 求 增加 一 个 页 面 .. 





} 
// 客 户 要 求 对 现 有 界面 做 修改 
public void change() { 








System,out,println(" 客 户 要求 修 改 一 个 页 面 .， 





} 
// 甲 方 是 老大 ， 要 求 删除 一 些 页 面 
public void delete() { 





System.out.println(" 客 户 要 求 删除 一 个 页 面 ,. 








} 
// 所 有 的 增 、 删 、 改 都 要 给 出 计划 
public void plan() { 








System.out.printlLn(" 客 户 要 求 页 面 变更 计划 , ， 


最 后 看 代码 组 。 这 个 组 的 成 员 一 般 比 较 沉 问 ， 不 多 说 话 ， 但 多 做 事 
儿 ， 这 是 这 个 组 的 典型 特点 。 人 代码 组 CodeGroup 类 如 代码 清单 15-4 所 


钞 。 


代码 清单 15-4 代码 组 


public class CodeGroup extends Group { 
// 客 户 要 求 代码 组 过 去 和 他 们 谈 
public void find() { 
System.out.println(" 找 到 代码 组 ..."); 











} 
// 客 户 要 求 增加 一 项 功能 
public void add() { 


Ey 


Wy 


2 


a 








System.out.println(" 客 户 要 求 增加 一 项 功能 





} 
// 客 户 要 求 修改 一 项 功能 
public void change() { 
System,out,println(" 客 户 要 求 修改 一 项 功能 


} 
// 客 户 要 求 删 除 一 项 功能 
public void delete() { 











System.out.println(" 客 户 要 求 删 除 一 项 功能 ，， 





} 
// 客 户 要 求 给 出 变更 计划 
public void plan() { 


} 








System.out.println(" 客 户 要求 代 码 变更 计划 , ， 


1) 


a) 


Wy 


整个 项 目的 3 个 支柱 都 已 经 产生 了 ， 那 看 客户 怎么 和 我 们 谈 。 客 户 
刚 开始 提交 了 他 们 自己 写 的 一 份 比较 完整 的 需求 ， 需 求 组 根据 这 份 需求 
写 了 一 份 分 析 说 明 书 ， 客 户 看 后 ， 要 求 增加 需求 ， 该 场景 如 代码 清单 





15-5 所 示 O 


代码 清单 15-5 场景 类 


public class Client { 
public static void main(String[] gS) { 


// 首 先 客户 找到 需求 组 说 ， 过 来 谈 需 求 ， 并 修改 








System.out.println("----------- 客户 要 求 增 加 一 项 需求 - - - -. 


Group rg = new RequirementGroup () ; 
// 找 到 需求 组 

rg.find( ); 

// 增 加 一 个 需求 

rg.add( ); 

// 要 求 变 更 计划 

rg.plan( ); 








CE 


运行 的 结果 如 下 所 示 : 








找到 需求 组 … 




















客户 要 求 增加 一 项 需求 … 


























客户 要 求 需 求 变更 计划 .… 


客户 的 需求 暂时 满足 了 ， 过 了 一 段 时 间 ， 客 户 又 要 求 “ 界 面 多 男 了 
一 个 ， 过 来 谈 谈 ”， 于 是 又 有 一 次 场景 变化 ， 如 代码 清单 15-6 所 示 。 


代码 清单 15-6 变化 的 场景 类 


public class Client { 
public static void main(String[] LoS) { 

// 首 先 客户 找到 美工 组 说 ， 过 来 谈 页 面 ， 并 修改 
System.out.println("---------- 客户 要 求 删 除 页 面 -----. 
Group pg = new PageGroup(); 
// 找 到 需求 组 
pg,find() ， 
// 删 除 一 项 需求 
pg.delete( ); 
// 要 求 变 更 计划 
pg.plan(); 











一 


运行 结果 如 下 所 示 : 








找到 美工 组 .… 











客户 要 求 删除 一 个 页 面 … 

















客户 要 求 页 面 变 更 计划 .… 








好 了 ， 界 面 也 谈 过 了 ， 应 该 没什么 大 问题 了 吧 。 过 了 一 天 后 ， 客 户 


又 让 代码 组 过 去 ， 说 是 数据 库 设 计 问 题 ， 然 后 又 叫 美 工 组 过 去 ， 布 置 了 
一 堆 命 令 .…… 这 个 就 不 一 一 写 了 ， 大 家 应 该 能 够 体会 得 到 ! 问题 来 了 ， 
我 们 修改 可 以 ， 但 是 每 次 部 是 叫 一 个 组 去 ， 布 置 个 任务 ， 然 后 出 计划 ， 
每 次 都 这 样 ， 如 果 让 你 当 甲 方 ， 你 烦 不 烦 ? 而 且 这 种 方式 很 容易 出 错 

误 ， 并 且 还 真 发 生 过 。 客 户 把 美工 叫 过 去 了， 要 删除 ， 可 美工 说 需求 是 
这 么 写 的 ， 然 后 客户 又 命令 需求 组 过 去 ， 一 次 次 地 折腾 之 后 ， 客 户 也 烦 
躁 了 ， 于 是 直接 抓 住 我 这 个 项 目 经 理 说 : “我 不 管 你 们 内 部 怎么 安排 ， 

你 就 给 我 找 个 接头 负责 人 ， 我 告诉 他 怎么 做 ， 删 除 页 面 ， 增 加 功能 ， 你 
们 内 部 怎么 处 理 我 不 管 ， 我 就 告诉 他 我 要 干什么 就 成 了 .2 











我 一 听 ， 好 啊 ， 这 也 正 是 我 想 要 的 ， 我 们 项 目 组 的 兄 第 们 也 已经 受 
不 了 了 ， 于 是 我 改变 了 一 下 我 的 处 理 方式 ， 如 图 15-2 所 示 。 
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Es 一 一 一 一 了 


t+vold setCommand(String str) 
Hvoid Action() 


Client 






+void findal) 
+void add() 


+void deletel() 
t+void changel() 
t+void plan() 
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图 15-2 增加 负 贡 人 后 的 类 图 


在 原 有 的 类 图 上 增加 了 一 个 Invoker 类 ， 其 作用 是 根据 客户 的 命令 安 
排 不 同 的 组 员 进 行 工 作 ， 例 如 ， 客 户 说 “界面 上 删除 一 条 记录 ”，Invoker 
类 接收 到 该 String 类 型 命令 后 ， 通 知 美工 组 PageGroup 开 始 delete， 然 后 
再 找到 代码 组 CodeGroup 后 台 不 要 存 到 数据 库 中 ， 最 后 反馈 给 客户 一 个 
执行 计划 。 这 是 一 个 捍 好 的 方案 ， 但 是 客户 的 命令 是 一 个 String 类 型 
的 ， 这 有 非常 多 的 变化 ， 仅 仅 通 过 一 个 字符 串 来 传递 命令 并 不 是 一 个 非 
第 好 的 方案 ， 因 为 在 系统 设计 中 ， 字 符 串 没有 约束 力 ， 根 据 字 符 串 判断 





相关 的 业务 逻辑 不 是 一 个 优秀 的 解决 方案 。 那 怎么 才 是 一 个 优秀 的 方案 
呢 ? 解决 方案 是 : 对 客户 发 出 的 命令 进行 封装 ， 每 个 命令 是 一 个 对 象 ， 
避免 客户 、 负 责 人 、 组 员 之 间 的 交流 误差 ， 封 装 后 的 结果 就 是 客户 只 要 
说 一 个 命令 ， 我 的 项 目 组 就 立刻 开始 启动 ， 不 用 思考 、 解 析 命 令 字符 

串 ， 如 图 15-3 所 示 。 














+void final() 
+void addl() 
+void delete() 
+void changel) 
+void plan() 


#RequirementGroup rg = new RequirementGroup() 
#PageGroup pg = new PageGroup() 
#CodeGroup cg = new CodeGroup() 
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EE==== = 二 = 
+void setCommand(Command command) 
+vold Action() 






图 15-3 完美 的 类 图 


Command 抽 象 类 只 有 一 个 方法 execute， 其 作用 就 是 执行 命令 ， 子 
类 非常 坚决 地 实现 该 命令 ， 与 军队 中 类 似 ， 上 级 军官 给 士兵 发 布 命 令 : 
怜 上 这 个 旗杆 ! 然后 士兵 回答 : Yes,Sir! 完美 的 项 目 也 与 此 类 似 ， 客 户 
发 送 一 个 删除 页 面 的 命令 ， 接 头 负 贡 人 Invoker 接 收 到 命令 后 ， 立 刻 执行 
DeletePageCommand 的 execute 方 法 。 对 类 图 中 增加 的 几 个 类 说 明 如 下 。 


e Command 抽 象 类 : 客户 发 给 我 们 的 命令 ， 定 义 三 个 工作 组 的 成 员 
变量 ， 供 子 类 使 用 ， 定 义 一 个 抽象 方法 execute， 由 子 类 来 实现 。 


e CInvoker 实 现 类 : 项 目 接头 负责 人 ，setComand 接 收 客 户 发 给 我 们 
的 命令 ，action 方 法 是 执行 客户 的 命令 “〈 方 法 名 写成 是 action， 与 
command 的 execute 区 分 开 ， 避 免 混 消 ) 。 


其 中 ，Command 抽 象 类 是 整个 扩展 的 核心 ， 其 源 代 码 如 代码 清单 
15-7 所 示 。 


代码 清单 15-7 抽象 命令 类 


public abstract class Command { 
// 把 三 个 组 都 定义 好 ， 子 类 可 以 直接 使 用 
protected RequirementGroup rg = new RequirementGroup(); /7 时 
protected PageGroup pg = new PageGroup(); // 美 工 组 
protected CodeGroup cg = new CodeGroup(); // 代 码 组 
// 只 有 一 个 方法 ， 你 要 我 做 什么 事情 
public abstract void execute( ); 

















et 














抽象 类 很 简单 ， 具 体 的 实现 类 只 要 实现 execute 方 法 就 可 以 了 。 在 一 
个 项 目 中 ， 需 求 增 加 是 很 常见 的 ， 那 就 把 “增加 需求 ”定义 为 一 个 命令 
AddRequirementCommand 类 ， 如 代码 清单 15-8 所 示 。 


代码 清单 15-8 增加 需求 的 命令 


public class nocrequ i oment conmang extends Command { 
// 执 行 增加 一 项 需求 的 命令 
public void execute() { 
// 找 到 需求 组 
super.rg.find(); 
// 增 加 一 份 需求 
super.rg.add( ); 
// 给 出 计划 
super.rg.plan( ); 











页 面 变更 也 是 比较 频繁 发 生 的 ， 定 义 一 个 删除 页 面 的 命令 
DeletePageCommand 类 ， 如 代码 清单 15-9 所 示 。 


代码 清单 15-9 删除 页 面 的 命令 


public class DeletePageCommand extends Command { 
// 执 行 删除 一 个 页 面 的 命令 
public void execute() { 
// 找 到 页 面 组 
super .pg.find(); 
// 删 除 一 个 页 面 
super.rg.delete(); 
// 给 出 计划 
super.rg.plan( ); 


Command 抽 象 类 可 以 有 NN 个子 类 ， 如 增加 一 个 功能 命令 


(AddFunCommand) ， 删 除 一 份 需求 命令 
(DeleteRequirementCommand) 等 ， 这 里 束 不 再 描述 了 ， 只 要 是 由 客户 
产生 、 时 常 性 的 行为 都 可 以 定义 为 一 个 命令 ， 其 实现 类 都 比较 简单 ， 读 
者 可 以 自行 扩展 。 


客户 发 送 的 命令 已 经 确定 下 来 ， 我 们 再 看 负责 人 Invoker， 如 代码 清 
单 15-10 所 示 。 


代码 清单 15-10 负责 人 


public class Invoker { 
// 什 么 命令 
private Command command; 
// 客 户 发 出 命令 
public void setCommand(Command command){ 
this.command = command; 


} 

// 执 行 客户 的 命令 

public void action(){ 
this.command.execute( ); 

} 


这 更 简单 了 ， 负 责 人 只 要 接 到 客户 的 命令 ， 束 立刻 执行 。 我 们 模拟 
增加 一 项 需求 的 过 程 ， 如 代码 清单 15-11 所 示 。 


代码 清单 15-11 增加 一 项 需求 


public class Client { 
public static void main(String[] args) { 
// 定 义 我 们 的 接头 人 
Invoker xiaoSan = new Invoker(); // 接 头 人 就 是 小 三 
// 客 户 要 求 增 加 一 项 需求 
System.out,.println("------------ 客户 要 求 增加 一 项 需求 - - -. 
// 客 户 给 我 们 下 命令 来 

















Command RN new AddReduirementC 
// 接 头 人 接收 到 命令 
xiaoSan.setCommand(command); 

// 接 头 人 执行 命令 


xiaoSan.action( ) ; 


-一 


运行 结果 如 下 所 示 : 


bE 


























客户 要 求 增加 一 项 需求 … 























客户 要 求 需求 变更 计划 .… 


是 不 是 我 们 的 场景 类 简单 了 很 多 ? 客户 只 要 给 命 
简单 ! 非常 简单 ! 那 我 们 看 看 ， 如 果 客 户 要 求 删除 一 个 
改 有 多 大 ， 如 代码 清单 15-12 所 示 。 


代码 清单 15-12 删除 一 个 页 面 


public class Client { 
public static void main(String[] args) { 


// 定 义 我 们 的 接头 人 





ommand ( ) ; 


令 ， 我 马上 执行 。 


页 面 ， 我 们 的 修 


Invoker xiaoSan = new Invoker(); // 接 头 人 就 是 小 三 








// 客 户 要 求 增加 一 项 需求 

System.out .println("------------ 客户 要 
// 客 户 给 我 们 下 命令 来 

//Command command = new AddReduiremen 





Command oma new DeletePageComma 
// 接 头 人 接收 到 命令 
xiaoSan.setcommand(command ) ; 

// 接 头 人 执行 命令 


xiaoSan.action( ) ; 


求 删除 一 个 页 面 - - -. 


tCommand ( ) ， 
nd() ; 


I 


行 结 果 如 下 所 示 : 





























客户 要 求 需 求 变更 计划 .… 





看 到 上 面 用 粗 体 显示 的 代码 了 吗 ? 只 修改 了 这 人 么 多 ， 是 不 是 很 简 
单 ， 而 且 客 户 也 不 用 知道 到 后 由 谁 来 修改 ， 高 内 聚 的 要 求 体现 出 来 了 ， 
这 就 是 命令 模式 。 


15.2 命令 模式 的 定义 





命令 模式 是 一 个 高 内 聚 的 模式 ， 其 定义 为 : Encapsulate a request as 
an object,thereby letting you parameterize clients with different 
requests,queue or log requests,and support undoable operations. (将 一 个 请 
求 封 装 成 一 个 对 象 ， 从 而 让 你 使 用 不 同 的 请 求 把 客户 端 参数 化 ， 对 请 求 
排队 或 者 记录 请 求 日 志 ， 可 以 提供 命令 的 撤销 和 恢复 功能 。) 





命令 模式 的 通用 类 图 如 图 15-4 所 示 。 






Command 









+Execute() 


Receiver 


+Action() 


图 15-4 命令 模式 的 通用 类 图 


在 该 类 图 中 ， 我 们 看 到 三 个 角色 : 


e@ Receive 接 收 者 角色 


该 角色 就 是 干 活 的 角色 ， 命 令 传 递 到 这 里 是 应 该 被 执行 的 ， 有 具体 到 
我 们 上 面 的 例子 中 就 是 Group 的 三 个 实现 类 


e Command 命 令 角色 
要 执行 的 所 有 命令 都 在 这 里 声明 。 
e Invoker 调 用 者 角色 


接收 到 命令 ， 并 执行 命令 。 在 例子 中 ， 我 项目 经 理 ) 就 是 这 个 角 





命令 模式 比较 简单 ， 但 是 在 项 目 中 非常 频 演 地 使 用 ， 因 为 它 的 封装 
性 非常 好 ， 把 请 求 方 〈Invoker) 和 执行 方 Receiver) 分 开 了 ， 扩 展 性 
也 有 很 好 的 保障 ， 通 用 代码 比较 简单。 我 们 先 阅 读 一 下 Receiver 类 ， 如 
代码 清单 15-13 所 示 。 


代码 清单 15-13 通用 Receiver 类 


public abstract class Receiver { 
// 抽 象 接收 者 ， 定 义 每 个 接收 者 都 必须 完成 的 业务 


public abstract void doSomething(); 





} 





很 奇怪 ， 为 什么 Receiver 是 一 个 抽象 类 ? 那 是 因为 接收 者 可 以 有 多 
个 ， 有 多 个 就 需要 定义 一 个 所 有 特性 的 抽象 集合 一 一 抽象 的 接收 者 ， 其 
具体 的 接收 者 如 代码 清单 15-14 所 示 。 





代码 清单 15-14 具体 的 Receiver 类 


public class ConcreteReciver1 extends Receivert{ 
// 每 个 接收 者 都 必须 处 理 一 定 的 业务 逻辑 
public void doSomething(){ 
} 


public class ConcreteReciver2 extends Receivert{ 
// 每 个 接收 者 都 必须 处 理 一 定 的 业务 逻辑 
public void doSomething(){ 
} 

































































接收 者 可 以 是 N 个 ， 这 要 依赖 业务 的 具体 定义 。 命 
式 的 核心 ， 其 抽象 的 命令 类 如 代码 清单 15-15 所 示 。 


心 
下 
信 
法 
寺 
心 
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代码 清单 15-15 抽象 的 Command 类 


public abstract class Command { 
// 每 个 命令 类 都 必须 有 一 个 执行 命令 的 方法 
public abstract void execute( ) ， 





根据 环境 的 需求 ， 有 具体 的 命令 类 也 可 以 有 N 人 个， 其 实现 类 如 代码 清 
单 15-16 所 示 。 


代码 清单 15-16 具体 的 Command 类 


public class Concretecommand1 extends Command { 
// 对 哪个 Receiver 类 进行 命令 处 理 
private Receiver receiver; 

















// 构 造 函 数 传 递 接收 者 
public ConcreteCommandi(Receiver _receiver)t{ 
this.receiver = receiver; 


} 

// 必 须 实现 一 个 命令 

public void execute() { 
// 业 务 处 理 




















this.receiver.doSomething(); 


a 


public class ConcreteCommand2 extends Command { 
// 哪 个 Receiver 类 进行 命令 处 理 
private Receiver receiver; 























// 构 造 函 数 传 递 接收 者 
public ConcreteCommand2(Receiver _receiver)t{ 
this.receiver = _receiver,; 


} 

// 必 须 实现 一 个 命令 

public void execute() { 
// 业 务 处 理 
this.receiver.doSomething(); 























定义 了 两 个 具体 的 命令 类 ， 读 者 可 以 在 实际 应 用 中 扩展 该 命令 类 。 
在 每 个 命令 类 中 ， 通 过 构造 函数 定义 了 该 命令 是 针对 哪 一 个 接收 者 发 出 
的 ， 定 义 一 个 命令 接收 的 主体 。 调 用 者 非常 简单 ， 仅 实现 命令 的 传递 ， 
如 代码 清单 15-17 所 示 。 


代码 清单 15-17 调用 者 Invoker 类 


public class Invoker { 
private Command command ; 
// 受 气 包 ， 接 受命 令 
public void setCommand(Command _command)t{ 
this.command = _command 


} 

// 执 行 命令 

public void action( ){ 
this.command.execute( ); 

} 


调用 者 就 像 是 一 个 受气 包 ， 不 管 什么 命令 ， 都 要 接收 、 执 行 ! 那 我 
们 来 看 高 层 模块 如 何 调用 命令 模式 ， 如 代码 清单 15-18 所 示 。 


代码 清单 15-18 场景 类 


public class Client { 
public static void main(String[] args) { 





// 首 先 声明 调用 者 Invoker 
Invoker invoker = new Invoker(); 
// 定 义 接收 者 





Receiver receiver = new ConcreteReciveri1(); 

7// 定 文 一 个 发 送 给 接收 者 的 命 人 

Command command = new Concretecommand1(receiver ) ， 
// 把 命令 交 给 调用 者 去 执行 

invoker.setCcommand(command ) ; 

Invoker .action( ) ; 








一 个 完整 的 命令 模式 束 此 完成 ， 读 者 可 以 在 此 基础 上 进行 扩展 。 


15.3 命令 模式 的 应 用 
15.3.1 命令 模式 的 优点 


e 类 间 解 未 


调用 者 角色 与 接收 者 角色 之 间 没 有 任何 依赖 关系 ， 调 用 者 实现 功能 
时 只 需 调 用 Command 抽 象 类 的 execute 方 法 就 可 以 ， 不 需要 了 解 到 底 是 
哪个 接收 者 执行 。 





e 可 扩展 性 








Command 的 子 类 可 以 非常 容易 地 扩展 ， 而 调用 者 Invoker 和 高 层次 
的 模块 Client 不 产生 严重 的 代码 耦合 。 





e 命令 模式 结合 其 他 模式 会 更 优秀 


命令 模式 可 以 结合 责任 链 模式 ， 实 现 命令 族 解析 任务 ; 结合 模板 方 
法 模式 ， 则 可 以 减少 Command 子 类 的 膨胀 问题 。 


15.3.2 命令 模式 的 缺点 





命令 模式 也 是 有 缺点 的 ， 请 看 Command 的 子 类 : 如 果 有 NN 个 命令 ， 


问题 就 出 来 了 ，Command 的 子 类 束 可 不 是 几 个 ， 而 古 N 个 ， 这 个 类 膨胀 
得 非常 大 ， 这 个 就 需要 读者 在 项 目 中 慎重 考虑 使 用 。 





15.3.3 命令 模式 的 使 用 场景 


只 要 你 认为 是 命令 的 地 方 就 可 以 采用 命令 模式 ， 例 如 ， 在 GUI 开发 
中 ， 一 个 按钮 的 反击 是 一 个 命令 ， 可 以 采用 命令 模式 ; 模拟 DOS 命 令 的 
时 候 ， 妆 然 也 要 采用 命令 模式 ; 触发 一 反馈 机 制 的 处 理 等 。 





15.4 命令 模式 的 扩展 


15.4.1 未 讲 完 的 故事 


上 面 的 例子 我 们 还 没有 说 完 。 想 想 看 ， 客 户 要 求 增加 一 项 需求 ， 那 
是 不 是 页 面 也 增加 ， 同 时 功能 也 要 增加 呢 ? 如 果 不 使 用 命令 模式 ， 客 户 
就 需要 先 找 需求 组 ， 然 后 找 美工 组 ， 再 找 代 码 组 .…… 你 想 让 客户 跳楼 
啊 ! 使 用 命令 模式 后 ， 客 户 只 管 发 命令 模式 ， 例 如 ， 需 要 增加 一 项 需 
求 ， 没 问题 ， 我 内 部 调动 三 个 组 通力 合作 ， 然 后 把 结果 反馈 给 你 ， 这 也 
正 是 客户 需要 的 。 那 这 个 要 怎么 修改 呢 ?” 想 想 看 ， 很 简单 的 ! 在 
AddRequirementCommand 类 的 execute 方 法 中 增加 对 PageGroup 和 
CodePage 的 调用 就 可 以 了 ， 修 改 后 的 代码 如 代码 清单 15-19 所 示 。 





代码 清单 15-19 修改 后 的 增加 需求 


public class AddRequirementCommand extends Command { 

// 执 行 增加 一 项 需求 的 命令 

public void execute() { 
// 找 到 需求 组 
super.rg.find(); 
// 增 加 一 份 需求 
super.rg.add( ); 
// 页 面 也 要 增加 
super . pg.add( ); 
// 功 能 也 要 增加 
super.cg.add(); 
// 给 出 计划 
super.rg.plan( ); 




















看 看 ， 是 不 是 解决 问题 了 ? 客户 Client 只 需要 发 布 命令 ， 至 于 如 何 
执行 这 个 命令 ， 是 协调 一 个 对 象 ， 还 是 两 个 对 象 ， 都 不 需要 关心 ， 命 令 


模式 做 了 一 层 非 第 好 的 封装 。 


15.4.2 反悔 问题 





我 们 的 例子 说 到 这 里 是 不 是 应 该 真 的 结束 了 ? 不 ， 还 有 一 个 问题 会 
经 党 发生 的 : 客户 发 出 命令 ， 要 撤回 ， 怎 么 办 ? 就 类 似 你 使 用 Ctl+Z 组 
合 键 (undo 功 能 ) ， 发 出 一 个 命令 ， 在 没有 执行 《这 时 只 要 重新 
setCommand 就 可 以 了 ) 或 执行 后 撤回 〈 执 行 后 撤回 是 状态 变更 ) 该 怎 


么 实现 呢 ? 








有 两 种 方法 可 以 解决 : 一 是 结合 备 筷 录 模 式 还 原 最 后 状态 ， 该 方法 
适合 接收 者 为 状态 的 变更 情况 ， 而 不 适合 事件 处 理 ， 二 是 通过 增加 一 个 
新 的 命令 ， 实 现 事件 的 回 滚 。 例 子 中 的 “删除 一 个 页 面 ? 束 需要 一 个 反 命 
令 : 撤销 刚刚 删除 页 面 的 命令 ， 那 客户 发 出 这 样 一 个 命令 ， 我 们 该 怎么 
处 理 呢 ? 





我 们 这 样 思考 ， 反 命令 也 是 一 个 命令 ， 那 就 是 Command 的 一 个 子 
类 ， 筷 实现 的 功能 就 是 恢复 刚刚 删除 的 页 面 ， 然 后 我 们 再 思考 ， 谁 能 恢 
复 删除 的 页 面 呢 ? 当然 是 页 面 组 了 ， 于 是 作为 接收 者 的 页 面 组 必须 还 有 
一 个 方法 恢复 最 后 删除 的 页 面 ， 也 就 是 日 志 的 回 深 机 制 了 了 ， 指 定 一 个 页 














面 ， 回 深 回 去 。 分 析 完 毕 ， 我 们 来 看 实现 ， 注 意 : 以 下 为 示意 代码 ， 请 
读者 自行 在 应 用 中 进行 实现 。 修 正 后 的 Group 如 代码 清单 15-20 所 示 。 


代码 清单 15-20 修改 后 的 Group 类 


public abstract class Group { 

// 甲 乙 双方 分 开办 公 ， 你 要 和 那个 组 讨论 ， 你 首先 要 找到 这 个 组 
public abstract void find(); 
// 被 要 求 增加 功能 
public abstract void add(); 
// 被 要 求 删 除 功能 
public abstract void delete(); 
// 被 要 求 修改 功能 
public abstract void change( ) ， 
// 被 要 求 给 出 所 有 的 变更 计划 
public abstract void plan( ); 
// 每 个 接收 者 都 要 对 直接 执行 的 任务 可 以 回 深 
public void rollBack( ){ 

// 根 据 日 志 进 行 回 深 
} 



































仅仅 增加 了 一 个 rollBack 的 方法 ， 每 个 接收 者 都 可 以 对 自己 实现 的 
任务 进行 回 深 。 怎 么 回 深 ? 根据 事务 日 志 进 行 回 滚 ! 新 增加 的 一 个 命令 
CancelDeletePageCommand 实 现 撤销 刚刚 发 出 的 删除 命令 ， 如 代码 清单 
15-21 所 示 。 





代码 清单 15-21 撤销 命令 


public class CancelDeletePageCcommand extends Command { 
// 撤 销 删除 一 个 页 面 的 命令 
public void execute() { 
super.pg.rollBack( ); 
} 


然后 就 是 用 Invoker 进 行 调用 了 ， 客 户 选 择 了 执行 这 个 撤销 动作 ,区 
可 以 进行 撤销 操作 ， 该 示意 代码 确实 比较 简单 ， 真 正 实现 起 来 那 是 寞 营 
复杂 的 ， 为 什么 呢 ? 事务 日 志 处 理 是 非常 繁琐 的 处 理 机制 ， 想 想 数 据 库 
的 日 志 处 理 吧 ， 你 就 能 想象 出 这 个 日 志 有 多 复杂 ! 


15.5 最 佳 实践 


各 位 读者 可 能 已 经 发 党 了 这 样 的 问题 : 在 我 们 旅行 社 的 例子 中 ， 我 
们 的 Receiver 角 色 《〈 也 就 是 Group 的 三 个 实现 类 ) 并 没有 其 露 给 Client， 
而 在 通用 的 类 图 和 源码 中 却 出 现 了 Client 类 对 Receiver 角 色 的 依赖 ， 这 是 
为 什么 呢 ? 


如 果 你 发 现 了 这 个 问题 ， 则 说 明 你 阅读 得 非常 仔细 ， 好 习惯 ! 每 一 
个 模式 到 实际 应 用 的 时 候 都 有 一 些 变 形 ， 命 令 模式 的 Receiver 在 实际 应 
用 中 一 般 都 会 被 封 疲 挥 (除非 非常 必要 ， 例 如 撤销 处 理 ) ， 那 是 因为 在 
项 目 中 : 约定 的 优先 级 最 高 ， 每 一 个 命令 是 对 一 个 或 多 个 Receiver 的 封 
装 ， 我 们 可 以 在 项 目 中 通过 有 意义 的 类 名 或 命令 名 处 理 命令 角 色 和 接收 
者 角色 的 耦合 关系 《这 就 是 约定 ) ， 减 少 高 层 模块 (Client 类 ) 对 低层 
模块 (Receiver 角 色 类 ) 的 依赖 关系 ， 提 高 系统 整体 的 稳定 性 。 因 此 ， 
建议 大 家 在 实际 的 项 目 开 发 时 采用 封闭 Receiver 的 方式 〈 当 然 了 ， 仁 者 
见 仁 ， 智 者 见 智 ) ， 减 少 Client 对 Reciver 的 依赖 ， 该 方案 只 是 对 
Commandd 抽 象 类 及 其 子 类 有 一 定 的 修改 ，Command 类 如 代码 清单 15-22 
所 示 。 











代码 清单 15-22 完美 的 Command 类 


public abstract class Command { 
// 定 义 一 个 子 类 的 全 局 共享 变量 


protected final Receiver receliver ; 

// 实 现 类 必须 定义 一 个 接收 者 

public Command(Receiver _receiver)t{ 
this.receiver = _receiver; 


// 每 个 命令 类 都 必须 有 一 个 执行 命令 的 方法 
public abstract void execute() 














-一 


在 Command 父 类 中 声明 了 一 个 接收 者 ， 通 过 构造 函数 约定 每 个 具体 
命令 都 必须 指定 接收 者 ， 当 然 根 据 开 发 场景 要 求 也 可 以 有 多 个 接收 者 ， 
那 就 需要 用 集合 类 型 。 我 们 来 看 其 体 命令 ， 如 代码 清单 15-23 所 示 。 











代码 清单 15-23 具体 的 命令 


public class Concretecommand1 extends Command { 
// 声 明 自 己 的 默认 接收 者 

public ConcreteCommand1( ){ 
super(new ConcreteReciver1()); 


} 

// 设 置 新 的 接收 者 

public ConcreteCommandi(Receiver _receiver)t{ 
super(_receiver); 











} 

// 每 个 具体 的 命令 都 必须 实现 一 个 命令 

public void execute() { 
// 业 务 处 理 
super.receiver.doSomething(); 

















} 


public class ConcreteCommand2 extends Command { 
// 声 明 自 己 的 默认 接收 者 

public ConcreteCommand2(){ 
super(new ConcreteReciver2() ) ; 


} 

// 设 置 新 的 接收 者 

public ConcreteCommand2(Receiver _receiver)t{ 
super(_receiver); 


} 
// 每 个 具体 的 命令 都 必须 实现 一 个 命令 
public void execute() { 

// 业 务 处 理 


























Super .receiver .doSomething() ; 





这 确实 简化 了 很 多 ， 每 个 命令 完成 单一 的 职责 ， 而 不 是 根据 接收 者 
的 不 同 完成 不 同 的 职责 。 在 高 层 模 块 的 调用 时 就 不 用 考虑 接收 者 是 谁 的 
问题 ， 如 代码 清单 15-24 所 示 。 


代码 清单 15-24 场景 类 


public class Client { 

public static void main(String[] args) { 
// 首 先 声明 调用 者 Invoker 
Invoker invoker = new Invoker(); 
// 定 义 一 个 发 送 给 接收 者 的 命令 
Command command = new ConcreteCommand1(); 
// 把 命令 交 给 调用 者 去 执行 
invoker.setCcommand(command ) ; 
Invoker ,action( ) ; 











高 层次 的 模块 不 需要 知道 接收 者 ，Perfect! 读 者 可 以 在 实际 应 用 中 采 
用 该 模式 ， 看 看 威力 如 何 。 





第 16 草 ”责任 链 模 式 


16.1 古代 妇女 的 杉 锁 一 “三 从 四 德 ” 








中 国 古 代 对 妇女 制定 了 “三 从 四 德 " 的 道德 规范 , “三 从 ”是 指 “ 未 嫁 
从 父 、 既 嫁 从 夫 、 夫 死 从 子 ”。 也 就 是 说 ， 一 位 女性 在 结婚 之 前 要 听从 
于 父亲 ， 结 婚 之 后 要 听从 于 丈夫 ， 如 果 丈 夫 死 了 还 要 听从 于 儿子 。 举 例 
来 说 ， 如 果 一 位 女性 要 出 去 逛街 ， 在 她 出 嫁 前 必须 征 得 父亲 的 同意 ， 出 
嫁 之 后 必须 获得 丈夫 的 许可 ， 那 丈夫 死 了 怎么 办 ? 那 就 得 问 问 儿子 是 否 
允许 自己 出 去 选 街 。 估 计 你 接 下 来 马上 要 问 :“ 要 是 没有 儿子 怎么 
办 ? ” 那 就 请 示 小 板子、 侄子 等 。 在 父系 社会 中 ， 妇 女 只 占 从 属地 位 ， 
现在 想 想 中 国 古 代 的 妇女 还 是 挺 悲惨 的 ， 连 逛街 都 要 多 番 请 示 。 作 为 父 
亲 、 丈 夫 或 儿子 ， 只 有 两 种 选择 : 要 不 承担 起 责任 来 ， 允 许 她 或 不 允许 
她 逛街， 要 不 就 让 她 请 示 下 一 个 人 ， 这 是 整个 社会 体系 的 约束 ， 应 用 到 
我 们 项 目 中 就 是 业务 规则 。 下 面 来 看 如 何 通过 程序 来 实现 “三 从 ”， 需 求 
很 简单 :通过 程序 描述 一 下 古代 妇女 的 “三 从 ”制度 。 好 ， 我 们 先 来 看 类 
图 ， 如 图 16-1 所 示 。 
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图 16-1 妇女 “三 从 ”类 图 


类 图 非常 简单 ，IHandler 是 三 个 有 决策 权 对 象 的 接口 ，IWomen 是 女 
性 的 代码 ， 其 实现 也 非常 简单 ，IWomen 如 代码 清单 16-1 所 示 。 


代码 清单 16-1 女性 接口 


public interface IWomen { 
// 获 得 个 人 状况 
public int getType(); 
// 获 得 个 人 请 示 ， 你 要 干什么 ? 出 去 和 逛街 ? 约会 ?还 是 看 电影 ? 
public String getRequest ( ) ; 











一 


女性 接口 仅 两 个 方法 ， 一 个 是 取得 当前 的 个 人 状况 getType， 通 过 
返回 值 决定 是 结婚 了 还 是 没 结婚 、 丈 夫 是 否 在 世 等 ， 另 外 一 个 方法 
getRequest 是 要 请 示 的 内 容 ， 要 出 去 逛街 还 是 吃饭 ， 其 实现 类 如 代码 清 


单 16-2 所 示 。 


代码 清单 16-2 古代 妇女 


public class Women implements IWoment{ 
/* 
* 通过 一 个 Int 类 型 的 参数 来 描述 妇女 的 个 人 状况 
* 工 - -未 出 嫁 




















private int type=0; 

// 妇 女 的 请 示 

private String request = ""，; 

// 构 造 函 数 传递 过 来 请 求 

public Women(int _type,String _request)t{ 
this.type = _type; 
this.request = _request; 














} 

// 获 得 自己 的 状况 

public int getType(){ 
return this.type; 


} 

// 获 得 妇女 的 请 求 

public String getRequest(){ 
return this.request 

} 











我 们 使 用 数字 来 代表 女性 的 不 同 状态 : 1 是 未 结婚 ; 2 是 已 经 结婚 
的 ， 而 且 丈 夫 健在 ;3 是 丈夫 去 世 了 。 从 整个 设计 上 分 析 ， 有 处 理 权 的 
人 “如 父亲 、 丈 夫 、 儿 子 ) 才 是 设计 的 核心 ， 他 们 是 要 处 理 这 些 请 求 
的 ， 我 们 来 看 有 处 理 权 的 人 员 接 口 IHandler， 如 代码 清单 16-3 所 示 。 





代码 清单 16-3 有 处 理 权 的 人 员 接 口 


public interface IHandler { 
// 一 个 女性 (女儿 、 妻 子 或 者 母亲 〉 要 求 选 街 ， 你 要 处 理 这 个 请 求 
public void HandleMessage(IWomen women); 






































非常 简单 ， 有 处 理 权 的 人 对 妇女 的 请 求 进行 处 理 ， 分 别 有 三 个 实现 
类 ， 在 女儿 没有 出 巡 之 前 父亲 是 有 决定 权 的 ， 其 实现 类 如 代码 清早 16-4 
所 示 。 





代码 清单 16-4 父亲 类 


public class Father implements IHandler { 
// 未 出 嫁 的 女儿 来 请 示 父 亲 
public void HandleMessage(IWomen women) { 
System.out.println(" 女 儿 的 请 示 是 : "+women ,getReduest() 
System.out,printJln(" 父 亲 的 答复 是 :同意 " ) ， 











在 女性 出 巡 后 ， 丈 夫 有 决定 权 ， 如 代码 清早 16-5 所 示 。 


代码 清单 16-5 丈夫 类 


public class Husband implements IHandler { 
// 妻 子 向 丈夫 请 示 
public void HandleMessage( IWomen women) { 


System,out.println(" 妻 子 的 请 示 是 : "+women .getRequest(). 
System.out .println(" 丈 夫 的 答复 是 : 同意 ")， 














在 女性 丧偶 后 ， 对 母 杀 提出 的 请 求 儿子 有 决定 权 ， 如 代码 清单 16-6 
所 示 。 


代码 清单 16-6 儿子 类 


public class Son implements IHandler { 
// 母 亲 问 儿子 请 示 
public void HandleMessage(IWomen women) { 
System.out .println(" 母 杀 的 请 示 是 : "+women .getRequest() 
System.out.println(" 儿 子 的 答复 是 : 同意 " ) ; 

















以 上 三 个 实现 类 非常 简单 ， 只 有 一 个 方法 ， 处 理 女儿 、 妻 子 、 母 杀 
提出 的 请 求 ， 我 们 来 模拟 一 下 一 个 古代 妇女 出 去 逛街 是 如 何 请 示 的 ， 如 





代码 清单 16-7 所 示 。 


代码 清单 16-7 场景 类 


public class Client { 
public static void main(String[|] args) { 
// 随 机 挑选 几 个 女性 
Random rand = new Random( ) ; 
ArrayList<IWomen> arrayList = new ArrayList(); 
for(int i=0;i<5;i++)t{ 
arrayList.add(new Women(rand.nextInt(4), "我 要 


} 

// 定 义 三 个 请 示 对 象 

IHandler father = new Father(); 

IHandler husband = new Husband ( ) ， 

IHandler son = new Son(); 

for(IWomen women:arrayList)t{ 

if(women,getType() ==1){ // 未 结婚 少女 ， 请 示 父 亲 
System.out.println("\n-------- 女儿 同 父 ; 
father.HandleMessage (women ) ， 

}else if(women.getType() ==2){ // 己 婚 少 妇 ， 请 
System.out.printin("\Nn-------- 妻子 向 丈 : 
husband.HandleMessage(women ) ; 

}else if(women.getType() == 3){ // 母 亲 请 示 儿 子 
System,out.println('"Nxn-------- 母亲 向 儿 : 
son.HandleMessage(women ); 
































}elsef 
// 暂 时 什么 也 不 做 


首先 是 通过 随机 方法 产生 了 5 个 古代 妇女 的 对 象 ， 然 后 看 她 们 是 如 
何 束 选 街 这 件 事 去 请 示 的 ， 运 行 结果 如 下 所 示 〈 由 于 是 随机 的 ， 您 看 到 
的 结果 可 能 和 这 里 有 所 不 同 ) : 





-一 女儿 向 父亲 请 示 ------- 














女儿 的 请 示 是 : 我 要 出 去 逛街 





父亲 的 答复 是 : 同意 











-母亲 向 儿子 请 示 ------- 














母亲 的 请 示 是 : 我 要 出 去 逛街 








儿子 的 答复 是 : 同意 





人 妻子 向 丈夫 请 示 ----- 














妻子 的 请 示 是 : 我 要 出 去 逛街 
丈夫 的 答复 是 : 同意 





本 女儿 向 父亲 请 示 ------- 














女儿 的 请 示 是 : 我 要 出 去 逛街 





父 杀 的 答复 是 : 同意 





“三 从 四 德 ”的 旧 社 会 规范 已 经 完整 地 表现 出 来 了 ， 你 看 谁 向 谁 请 示 
都 定义 出 来 了 ， 但 是 你 是 不 是 发 现 这 个 程序 写 得 有 点 不 舒服 ? 有 扣 别 
扭 ? 有 点 想 重 构 它 的 感觉 ? 那 就 对 了 ! 这 段 代码 有 以 下 几 个 问题 : 

















e 职责 界定 不 清晰 


对 女儿 提出 的 请 示 ， 应 该 在 父 杀 类 中 做 出 决定 ， 父 杀 有 责任 、 有 义 
务 处 理 女 儿 的 请 示 ， 因 此 Father 类 应 该 是 知道 女儿 的 请 求 目 己 处 理 ， 而 
不 是 在 Client 类 中 进行 组 装 出 来 ， 也 就 是 说 原本 应 该 是 父亲 这 个 类 做 的 
事情 抛 给 了 其 他 关 进 行 处 理 ， 不 应 该 是 这 样 的 。 


e 代码 腕 肿 


我 们 在 Client 类 中 写 了 证 ..else 的 判断 条 件 ， 而 且 能 随 着 能 处 理 该 类 
型 的 请 示人 员 越 多 ，if...else 的 判断 就 越 多 ， 想 想 看 ， 胱 肿 的 条 件 判 断 还 


怎么 有 可 读 性 ? ! 


这 是 什么 意思 呢 ， 我 们 要 根据 women 的 type 来 决定 使 用 IHandler 的 
那个 实现 类 来 处 理 请 求 。 有 一 个 问题 是 如 果 IHandler 的 实现 类 继续 扩 
展 怎么 办 ?修改 Client 类 ? 与 开 闭 原则 违背 了 ! 


妻子 只 能 向 丈夫 请 示 吗 ? 如果 妻子 (比如 一 个 现代 女性 穿 越 到 古代 
了 ， 不 懂 什 么 “三 从 四 德 *) 向 自己 的 父亲 请 示 了 ， 父 羔 应 该 做 何 处 理 ? 
我 们 的 程序 上 可 没有 体现 出 来 ， 多 辑 失 败 了 ! 


既然 有 这 么 多 的 问题 ， 那 我 们 要 想 办 法 来 解决 这 些 问题 ， 我 们 先 来 
分 析 一 下 需求 ， 女 性 提出 一 个 请 示 ， 必 和 然 要 获得 一 个 答复 ， 角 管 是 同意 
还 是 不 同意 ， 总 之 是 要 一 个 答复 的 ， 而 且 这 个 答复 是 唯一 的 ， 不 能 说 是 
父 杀 作 出 一 个 决断 ， 而 丈夫 也 作出 了 一 个 决断 ， 也 即 是 请 示 传 递 出 去 ， 
必然 有 一 个 唯一 的 处 理 人 给 出 唯一 的 答复 ，OK， 分 析 完 毕 ， 收 工 ， 重 
新 设计 ， 我 们 可 以 抽象 成 这 样 一 个 结构 ， 女 性 的 请 求 先 发 送 到 父 杀 类 ， 
父 杀 类 一 看 是 目 己 要 处 理 的 ， 惑 作出 回应 处 理 ， 如 果 女 儿 已 经 出 媒 了 ， 
那 就 要 把 这 个 请 求 转发 到 女 嫣 来 处 理 ， 那 女婿 一 旦 去 天 国 报道 了 ， 那 就 














由 儿子 来 处 理 这 个 请 求 ， 类 似 于 如 图 16-2 所 示 的 顺序 处 理 图 。 
































应 























女性 请 示 PE 父亲 一 =》 丈夫 = 儿子 
父亲 做 出 回应 ， | 
丈夫 做 出 回应 
< 儿子 做 出 回应 








图 16-2 女性 请 示 的 顺序 处 理 图 





父 杀 、 丈 夫 、 儿 子 每 个 节点 有 两 个 选择 : 要 么 承担 贡 任 ， 做 出 回 


; 要 么 把 请 求 转发 到 后 序 环 节 。 结 构 分 析 得 已 经 很 清楚 了 ， 那 我 们 看 





怎么 来 实现 这 个 功能 ， 类 图 重新 修正 ， 如 图 16-3 所 示 。 


setNext0: 设置 下 一 个 处 理 环节 是 谁 
古代 女性 的 代表 response(): 回应 ， 各 个 实现 类 实现 






+mt getType() Ns 
+String getRequest() 


hanlderMessage(): 处 理 请 求 















[| 
+final vold Handle Message(IWomen women) 
+void setNext(Handler handler) 

#yoid response(IWomen women) 


图 16-3 顺序 处 理 的 类 图 


从 类 图 上 看 ， 三 个 实现 类 Father、Husband、Son 只 要 实现 构造 函数 
和 父 类 中 的 抽象 方法 response 束 可 以 了 ， 具 体 由 谁 处 理 女 性 提出 的 请 
求 ， 都 已 经 转移 到 了 Handler 抽 象 类 中 ， 我 们 来 看 Handler 怎 么 实现 ， 如 
代码 清单 16-8 所 示 。 





代码 清单 16-8 修改 后 的 Handler 类 


public abstract class Handler { 

public final static int FATHER_LEVEL_ REQUEST = 

public final static int HUSBAND_ LEVEL REQUEST 

public final static int SON_LEVEL REQUEST = 3; 

// 能 处 理 的 级 别 

private int level =0; 

// 责 任 传 递 ， 下 一 个 人 责任 人 是 谁 

private Handler nextHandJer 

// 每 个 类 都 要 说 明 一 下 自己 能 处 理 哪些 请 求 

public Handler(int _level)t{ 
this.level = _level; 


} 
// 一 个 女性 (女儿 、 妻 子 或 者 是 母亲 ) 要 求 逛 街 ， 你 要 处 理 这 个 请 求 
public final void HandleMessage(IWomen women){ 
if(women.getType() == this.level)t{ 
this.response(women); 
}elsef{ 
if(this.nextHandler != null){ // 有 后 续 环 节 ， 才 1] 
this.nextHandler .HandleMessage(women); 
}else{ // 已 经 没有 后 续 处 理 人 了 ， 不 用 处 理 了 
System.out,.println("--- 没 地 方 请 示 了 ， 按 不 
} 


1; 
= 22 






































































































































} 

/* 

* 如 果 不 属 于 你 处 理 的 请 求 ， 你 应 该 让 她 找 下 一 个 环节 的 人 ， 如 女儿 出 嫁 了 ， 

* 还 向 父亲 请 示 是 否 可 以 逛街 ， 那 父亲 就 应 该 告诉 女儿 ， 应 该 找 丈 夫 请 示 

A 

public void setNext(Handler _handler)t{ 
this.nextHandler = _handler; 









































} 
// 有 请 示 那 当然 要 回应 
protected abstract void response(IWomen women); 











方法 比较 长 ， 但 是 还 是 比较 简单 的 ， 读 者 有 没有 看 到 ， 其 实在 这 里 
也 用 到 模板 方法 模式 ， 在 模板 方法 中 判断 请 求 的 级 别 和 当前 能 够 处 理 的 
级 别 ， 如 果 相 同 则 调用 基本 方法 ， 做 出 反馈 ， 如 果 不 相等 ， 则 传递 到 下 
一 个 环节 ， 由 下 一 环节 做 出 回应 ， 如 果 已 经 达到 环节 结尾 ， 则 直接 做 不 
同意 处 理 。 基 本 方法 response 需 要 各 个 实现 类 实现 ， 每 个 实现 类 只 要 实 
现 两 个 职责 : 一 是 定义 自己 能 够 处 理 的 等 级 级 别 ， 二 是 对 请 求 做 出 回 
应 ， 我 们 首先 来 看 首 节点 Father 类 ， 如 代码 清单 16-9 所 示 。 











代码 清单 16-9 父亲 类 


public class Father extends Handler { 
// 父 亲 只 处 理 女 儿 的 请 求 
public Father()t{ 
super (Handler ,FATHER_LEVEL_REQUEST ) ， 























} 

// 父 杀 的 答复 

protected void response(IWomen women) { 
System,out.println("-------- 女儿 向 父亲 请 示 ------- "); 





System.out.println(women.getRequest()); 
System.out .println(" 父 杀 的 答复 是 :同意 \n")， 











丈夫 类 定义 自己 能 处 理 的 等 级 为 2 的 请 示 ， 如 代码 清单 16-10 所 示 。 


代码 清单 16-10 丈夫 类 





public class Husband extends Handler { 
// 丈 夫 只 处 理 妻 子 的 请 求 
public Husband(){ 
super (Handler .HUSBAND_LEVEL_ REQUEST ) ， 


} 

// 丈 夫 请 示 的 答复 

protected void response(IWomen women) { 
System.out.printJn("-------- 妻子 向 丈夫 请 示 ------- 3 
































System.out .println(women.getReduest() ) ; 
System.out.println(" 丈 夫 的 答复 是 : 同意 \n" ) ; 


儿子 类 只 能 处 理 等 级 为 3 的 请 示 ， 如 代码 清单 16-11 所 示 。 


代码 清单 16-11 儿子 类 


public class Son extends Handler { 
// 儿 子 只 处 理 母 杀 的 请 求 
public Son(){ 
super (Handler .SON_LEVEL_ REQUEST); 





























} 

// 儿 子 的 答复 

protected void response(IWomen women) { 
System,out,.println("-------- 母亲 向 儿子 请 示 ------- "); 





System.out.println(women.getRequest()); 
System.out.println(" 儿 子 的 答复 是 : 同意 \n")， 





这 三 个 类 都 很 简单 ， 构 造 方法 是 必须 实现 的 ， 父 类 框 定子 类 必须 有 
一 个 显 式 构造 函数 ， 子 类 不 实现 编译 不 通过 。 通 过 构造 方法 我 们 设置 了 
各 个 类 能 处 理 的 请 求 类 型 ，Father 只 能 处 理 请 求 类 型 为 1 (也 就 是 女儿 ) 
的 请 求 ， Husband 只 能 处 理 请 求 类 型 类 为 2〈 也 就 是 妻子 ) 的 请 求 ， 儿 子 
只 能 处 理 请 求 类 型 为 3〈 也 就 是 母亲 ) 的 请 求 ， 那 如 果 请 求 类 型 为 4 的 该 
如 何 处 理 呢 ?在 Handler 中 我 们 已 经 判断 了 ， 如 何 没 有 相应 的 处 理 者 
(也 就 是 没有 下 一 环节 ) ， 则 视 为 不 同意 。 











Women 类 的 接口 没有 任何 变化 ， 请 参考 图 16-1 所 示 。 


实现 类 稍微 有 些 变 化 ， 如 代码 清单 16-12 所 示 。 





代码 清单 16-12 女性 类 


public class Women implements IWoment{ 
/* 
* 通过 一 个 Int 类 型 的 参数 来 描述 妇女 的 个 人 状况 
* 1-- 未 出 嫁 




















private int type=0; 

// 妇 女 的 请 示 

private String request = ""，; 

// 构 造 函 数 传递 过 来 请 求 

public Women(int _type,String _request)t{ 
this.type = _type; 
// 为 了 便于 显示 ， 在 这 里 做 了 点 处 理 
switch(this.type)t{ 












































case 1: 
this.request = "女儿 的 请 求 是 : " + _request， 
break 
case 2: 
this.request = "妻子 的 请 求 是 : " + _reduest， 
break 
case 3: 
this.request = "母亲 的 请 求 是 : " + _request， 
} 
} 
// 获 得 自己 的 状况 


public int getType(){ 
return this.type; 


} 

// 获 得 妇女 的 请 求 

public String getRequest(){ 
return this.request,; 

} 











为 了 展示 结果 清晰 一 点 ，Women 类 做 了 一 些 改变 。 我 们 再 来 看 
Client 类 是 怎么 描述 古代 这 一 个 礼节 的 ， 如 代码 清单 16-13 所 示 。 


代码 清单 16-13 场景 类 


public class 
public s 


在 Client 中 设置 请 求 的 传递 顺序 ， 先 同 父 


Client { 

tatic void main(String[] args) { 

// 随 机 挑选 几 个 女性 

Random rand = new Random( ) ; 

ArrayList<IWomen> arrayList = new ArrayList(); 
for(int 1I=0;1I<5;I++){ 


arrayList.add(new Women(rand.nextInt(4)," 


} 

// 定 义 三 个 请 示 对 象 

Handler father = new Father( ) ; 

Handler husband = new Husband ( ) 

Handler son = new Son(); 

// 设 置 请 示 顺 序 

father.setNext (husband); 

husband. setNext (son); 

for(IWomen women:arrayList)t{ 
father.HandleMessage (women ) ; 

} 














我 要 





杀 请 示 ， 不 是 父 杀 应 该 解 


上 上 
L 


决 的 问题 ， 则 由 父 羔 传递 到 丈夫 类 解决 ， 右 不 是 丈 夫 类 解决 的 问题 则 传 
加 到 儿子 类 解决 ， 最 终 的 结果 必然 有 一 个 返回 ， 其 运行 结果 如 下 所 示 。 


ee 雪子 向 丈夫 请 示 ------- 





妻子 的 请 求 是 : 


丈夫 的 答复 是 : 














我 要 出 去 逛街 
同意 





Ee 女儿 向 父亲 请 示 ------ 


女儿 的 请 求 是 : 














我 要 出 去 逛街 








同意 





父亲 的 答复 是 : 








A 母亲 向 儿子 请 示 ------ 


母亲 的 请 求 是 : 














我 要 出 去 逛街 








儿子 的 答复 是 : 


同意 





雪子 向 丈夫 请 示 ------- 














妻子 的 请 求 是 : 我 要 出 去 逛街 
丈夫 的 答复 是 :同意 














he 





-本 灯 间 几 半 请 未 二 





母亲 的 请 求 是 : 我 要 出 去 逛街 





儿子 的 答复 是 : 同意 





结果 也 正确 ， 业 务 调用 类 Client 也 不 用 去 做 判断 到 底 是 需要 谁 去 处 
理 ， 而 且 Handler 抽 象 类 的 子 类 可 以 继续 增加 下 去 ， 只 需要 扩展 传递 链 
而 已 ， 调 用 类 可 以 不 用 了 解 变化 过 程 ， 甚 至 是 谁 在 处 理 这 个 请 求 都 不 用 
知道 。 在 这 种 模式 下 ， 即 使 现代 社会 的 一 个 小 太 妹 穿越 到 古代 《例如 掉 
入 时 空 隧道 ， 或 者 时 空 突然 扭转 ， 甚 全 是 突然 魔法 显灵 ) ， 对 “三 从 四 
德 ”没有 任何 了 解 也 可 以 自由 地 应 付 ， 反 正 只 要 请 示 父 羔 束 可 以 了 ， 访 
父 杀 处 理 就 父亲 处 理 ， 不 该 父亲 处 理 就 往 下 传递 。 这 就 是 责任 链 模式 。 











16.2 贡 任 链 模 式 的 定义 





责任 链 模式 定义 如 下 : 


Avoid coupling the sender of a request to its receiver by giving more 
than one object a chance to handle the request.Chain the receiving objects 
and pass the request along the chain until an object handles it. (使 多 个 对 象 
都 有 机 会 处 理 请 求 ， 从 而 避免 了 请 求 的 发 送 者 和 接受 者 之 间 的 耦合 天 
系 。 将 这 些 对 象 连 成 一 条 链 ， 并 沿 着 这 条 链 传递 该 请 求 ， 直 到 有 对 象 处 
ll 





责任 链 模 式 的 重点 是 在 “ 链 ” 上 ， 由 一 条 链 去 处 理 相 似 的 请 求 在 链 中 
决定 谁 来 处 理 这 个 请 求 ， 并 返回 相应 的 结果 ， 其 通用 类 图 如 图 16-4 所 


A 


Handler 四 
[ES 


+HandleRequest() Hsuccessor 














ConcreteHandler 


FO 
SE 
图 16-4 责任 链 模 式 通 用 类 图 


责任 链 模式 的 核心 在 “ 链 ” 上 ,，“ 链 ”是 由 多 个 处 理 者 ConcreteHandler 
组 成 的 ， 我 们 先 来 看 抽象 Handler 类 ， 如 代码 清单 16-14 所 示 。 


代码 清单 16-14 抽象 处 理 者 


public abstract class Handler { 
private Handler nextHandler; 
// 每 个 处 理 者 都 必须 对 请 求 做 出 处 理 
public final Response handleMessage(Request request)t 
Response response = null; 
// 判 断 是 否 是 自己 的 处 理 级 别 
if(this.getHandlerLevel().equals(request.getRequestL 
response = this.echo(request); 
}else{ // 不 属于 自己 的 处 理 级 别 
// 判 断 是 否 有 下 一 个 处 理 者 
if(this.nextHandler != null)t{ 
response = this.nextHandler.handleMes 













































































}elsef 


> 




















// 没 有 适当 的 处 理 者 ， 业 务 自行 处 理 











return response ，; 

















} 

// 设 置 下 一 个 处 理 者 是 谁 

public void setNext(Handler _handler)t{ 
this.nextHandler = _handler; 








} 

// 每 个 处 理 者 都 有 一 个 处 理 级 别 

protected abstract Level getHandlerLevel(); 

// 每 个 处 理 者 都 必须 实现 处 理 任务 

protected abstract Response echo(Request request); 

















抽象 的 处 理 者 实现 三 个 职责 : 一 是 定义 一 个 请 求 的 处 理 方法 
handleMessage， 唯 一 对 外 开放 的 方法 ;二 是 定义 一 个 链 的 编排 方法 
setNext， 设 置 下 一 个 处 理 者 ; 三 是 定义 了 具体 的 请 求 者 必须 实现 的 两 个 
方法 : 定义 自己 能 够 处 理 的 级 别 getHandlerLevel 和 具体 的 处 理 任务 





echo。 





注意 ”在 责任 链 模式 中 一 个 请 求 发 送 到 链 中 后 ， 前 一 节点 消费 部 
分 消息 ， 然 后 交 由 后 续 节 点 继续 处 理 ， 最 终 可 以 有 处 理 结果 也 可 以 没有 
处 理 结果 ， 读 者 可 以 不 用 理会 什么 纯 的 、 不 纯 的 责任 链 模式 。 同 时 ， 请 
读者 注意 handlerMessage 方 法 前 的 final 关 键 字 ， 可 以 阅读 第 10 章 的 模板 
方法 模式 。 








我 们 定义 三 个 具体 的 处 理 者 ， 以 便 可 以 组 成 一 个 链 ， 如 代码 清单 


16-15 所 示 。 


代码 清单 16-15 具体 处 理 者 


public class ConcreteHandler1 extends Handler { 
// 定 义 自己 的 处 理 逻 辑 
protected Response echo(Request request) { 

// 完 成 处 理 逻 辑 


return null; 













































































} 

// 设 置 自己 的 处 理 级 别 

protected Level getHandlerLevel() { 
// 设 置 自己 的 处 理 级 别 
return null; 























} 


public class ConcreteHandler2 extends Handler { 
// 定 义 自己 的 处 理 逻 辑 
protected Response echo(Request request) { 

// 完 成 处 理 逻 辑 


return null; 










































































} 

// 设 置 自己 的 处 理 级 别 

protected Level getHandlerLevel() { 
// 设 置 自 己 的 处 理 级 别 
return null; 


























public class ConcreteHandler3 extends Handler { 
// 定 义 自己 的 处 理 逻 辑 
protected Response echo(Request request) { 

// 完 成 处 理 逻 辑 


return null; 










































































} 

// 设 置 自己 的 处 理 级 别 

protected Level getHandlerLevel() { 
// 设 置 自 己 的 处 理 级 别 
return null; 





























在 处 理 者 中 涉及 三 个 类 : Level 类 负责 定义 请 求 和 处 理 级 别 ， 
Request 类 负责 封装 请 求 ，Response 负 责 封装 链 中 返回 的 结果 ， 该 三 个 类 
都 需要 根据 业务 产生 ， 读 者 可 以 在 实际 应 用 中 完成 相关 的 业务 填充 ， 其 
框架 代码 如 代码 清单 16-16 所 示 。 


代码 清单 16-16 模式 中 有 关 框 架 代 码 


public class 


Level { 














// 定 义 一 个 请 求 和 处 理 等 级 





public class 











Request { 


// 请 求 的 等 级 
public Level getRequestLevel(){ 





return null; 
































} 
public class Response { 
// 处 理 者 返回 的 数据 
} 
在 场景 类 或 高 层 模块 中 对 链 进行 组 装 ， 并 传递 请 求 ， 结果 ， 如 


代码 清单 16-17 所 示 。 


代码 清单 16-17 场景 类 


public class 


Client { 


public static void ero args) { 

















// 声 明 所 有 的 处 理 节点 

Handler handler1 = new ConcreteHandler1(); 

Handler handler2 = new ConcreteHandler2(); 

Handler handler3 = new ConcreteHandler3(); 

// 设 置 链 中 的 阶段 顺序 1- ->2- ->3 
handler1.setNext(handler2); 
handler2.setNext(handler3); 

// 提 交 请 求 ， 返 回 结果 

Response response = handleri.handlerMessage(new Redu 














在 实际 应 用 中 ， 一 般 会 有 一 个 封装 类 对 责任 模式 进行 封装 ， 也 就 是 


蔡 代 Client 类 ， 


直接 返回 链 中 的 第 一 个 处 理 者 ， 有 具体 链 的 设置 不 需要 高 


层次 模块 关系 ， 这 样 ， 更 简化 了 高 层次 模块 的 调用 ， 减 少 模块 间 的 灶 


合 ， 提 高 系统 的 灵活 性 。 


16.3 贡 任 链 模 式 的 应 用 


16.3.1 责任 链 模 式 的 优点 


责任 链 模 式 非常 显著 的 优点 是 将 请 求 和 处 理 分 开 。 请 求 者 可 以 不 用 
知道 是 谁 处 理 的 ， 处 理 者 可 以 不 用 知道 请 求 的 全 貌 ( 例 如 在 J2EE 项 目 开 
发 中 ， 可 以 剥离 出 无 状态 Bean 由 贡 任 链 处 理 ) ， 两 者 解 耦 ， 提 高 系统 的 
灵活 性 。 





16.3.2 责任 链 模式 的 缺点 


责任 链 有 两 个 非常 显著 的 缺点 : 一 是 性 能 问题 ， 每 个 请 求 都 是 从 链 
头 近 历 到 链 尾 ， 特 别 是 在 链 比 较 长 的 时 候 ， 性 能 是 一 个 非常 大 的 问题 。 
二 是 调试 不 很 方便 ， 特 别 是 链条 比较 长 ， 环 节 比 较 多 的 时 候 ， 由 于 采用 
了 类 似 递归 的 方式 ， 调 试 的 时 候 逻 辑 可 能 比较 复杂 。 


16.3.3 责任 链 模 式 的 注意 事项 
链 中 节点 数量 需要 控制 ， 避 免 出 现 超 长 链 的 情况 ， 一 般 的 做 法 是 在 


Handler 中 设置 一 个 最 大 节点 数量 ， 在 setNext 方 法 中 判断 是 否 己 经 是 超 
过 其 闵 值 ， 超 过 则 不 允许 该 链 建 立 ， 避 人 免 无 意识 地 破坏 系统 性 能 。 





16.4 最 佳 实践 


在 例子 和 通用 源码 中 Handler 是 抽象 类 ， 融 合 了 模板 方法 模式 ， 每 

个 实现 类 只 要 实现 两 个 方法 : echo 方 法 处 理 请 求 和 getHandlerLevel 获 得 
处 理 级 别 ， 想 想 单一 职责 原则 和 过 米 特 法 则 吧 ， 通 过 融合 模板 方法 模 

式 ， 各 个 实现 类 只 要 关注 的 自己 业务 逻辑 就 成 了 ， 至 于 说 什么 事 要 自己 
处 理 ， 那 就 让 父 类 去 决定 好 了 ， 也 就 是 说 父 类 实现 了 请 求 传递 的 功能 ， 

子 类 实现 请 求 的 处 理 ， 符 合 单一 职责 原则 ， 各 个 实现 类 只 完成 一 个 动作 
或 逻辑 ， 也 就 是 只 有 一 个 原因 引起 类 的 改变 ， 我 建议 大 家 在 使 用 的 时 候 
用 这 种 方法 ， 好 处 是 非常 明显 的 了 ， 子 类 的 实现 非常 简单 ， 责 任 链 的 建 
立 也 是 非常 灵活 的 。 























责任 链 模 式 屏 茹 了 请 求 的 处 理 过 程 ， 你 发 起 一 个 请 求 到底 是 谁 处 理 
的 ， 这 个 你 不 用 关心 ， 只 要 你 把 请 求 抛 给 贡 任 链 的 第 一 个 处 理 者 ， 最 终 
会 返回 一 个 处 理 结果 (当然 也 可 以 不 做 任何 处 理 ) ， 作 为 请 求 者 可 以 不 
用 知道 到 底 是 需要 谁 来 处 理 的 ， 这 是 员 任 链 模 式 的 核心 ， 同 时 员 任 链 模 
式 也 可 以 作为 一 种 补救 模式 来 使 用 。 举 个 简单 例子 ， 如 项 目 开 发 的 时 
候 ， 需 求 确认 是 这 样 的 : 一 个 请 求 〈 如 银行 客户 存款 的 币 种 ) ， 一 个 处 
理 者 (只 处 理 人 民 币 )， 但 是 随 着 业务 的 发 展 〈 改 革 开 放 了 嘛 ， 还 要 处 
理 美 元 、 日 元 等 ) ， 处 理 者 的 数量 和 类 型 都 有 所 增加 ， 那 这 时 候 就 可 以 
在 第 一 个 处 理 者 后 面 建立 一 个 链 ， 也 就 是 责任 链 来 处 理 请 求 ， 如 有 果 征 人 


民 币 ， 好 ， 还 是 第 一 个 业务 逻辑 来 处 理 ， 如 果 是 美元 ， 好 ， 传 递 到 第 二 
个 业务 逻辑 来 处 理 ， 日 元 、 欧 元 .…... 这 些 都 不 用 在 对 原 有 的 业务 逻辑 产 
生 很 大 改变 ， 通 过 扩展 实现 类 就 可 以 很 好 地 解决 这 些 需求 变更 的 问题 。 





责任 链 在 实际 的 项 目 中 使 用 也 是 比较 多 的 ， 我 曾经 做 过 这 样 一 个 项 
目 ， 界 面 上 有 一 个 用 户 注册 功能 ， 注 册 用 户 分 两 种 ， 一 种 是 VIP 用 户 ， 
也 就 是 在 该 单位 办 理 过 业务 的 ， 一 种 是 普通 用 户 ， 一 个 用 户 的 注册 要 填 
写 一 扒 信 息 ，VIP 用 户 只 比 普通 用 户 多 了 一 个 输入 项 : VIP 序列 号 。 注 
册 后 还 需要 激活 ，VIP 和 普通 用 户 的 激活 流程 也 是 不 同 的 ，VIP 是 自动 
发 送 邮 件 到 用 户 的 邮箱 中 就 算 激 活 了 ， 普 通用 户 要 发 送 短信 才能 激活 ， 
为 什么 呢 ? 获得 手机 号 码 以 后 好 发 广告 短信 啊 ! 项 目 组 就 采用 了 责任 链 
模式 ， 直 管 从 前 台 传 递 过 来 的 是 VIP 用 户 信息 还 是 普通 用 户 信息 ， 统 一 
传递 到 一 个 处 理 入 口 ， 通 过 责任 链 来 完成 任务 的 处 理 ， 类 图 如 图 16-5 所 









zzz 
Ia 
+vold HandleRequest(HashMap UserInfoMap) 


+void setNext(Handler handler) 
#yoid response(HashMap UserlInfoMap) 











CommonRegistev 





VIPRegistev 
c= 
[LU 


图 16-5 用 户 注册 类 图 


其 中 RegisterAction 是 继承 了 Strust2 中 的 ActionSupport， 实 现 HTTP 
传递 过 来 对 象 组 装 ， 组 装 出 一 个 HashMap 对 象 UserInfoMap， 传 递 给 
Handler 的 两 个 实现 类 ， 具 体 是 哪个 实现 类 来 处 理 的 ， 束 由 HashMap 上 的 
用 户 标 识 来 做 决定 了 ， 这 个 和 上 面 我 们 举 的 例子 很 类 似 ， 读 者 可 以 上 自行 
实现 。 





第 17 章 “” 狠 饰 模式 


17.1 罪恶 的 成 绩 单 


“中 庸 ” 是 中 国 颂 教 文化 的 集中 体现 ， 说 话 或 做 事情 都 不 能 太 直 接 ， 
需要 有 技巧 。 比 如 谈话 ， 如 果 你 要 批评 某 个 人 ， 你 不 能 一 上 来 就 说 他 这 
做 得 不 对 ， 那 也 做 得 不 对 ， 你 要 先 肯定 他 的 成 绩 ， 表 扬 一 下 优点 ， 然 后 
再 指出 不 足 ， 指 出 错误 的 地 方 ， 最 后 再 来 把 激励 ， 你 修改 了 这 些 缺 点 后 
有 哪些 好 处 ， 比 如 你 能 带 更 多 的 小 兵 、 升 职 等 。 如 果 你 一 上 来 就 是 一 顿 
批评 ， 你 上 卫 晤 看 ， 对 方 肯 定 古 不 服气 ， 甚 至 是 顶撞 你 说 : “此 处 不 养 
和 爷 ， 目 有 养分 处 ”， 于 是 甩 门 而 去 。 





这 是 说 话 ， 做 事情 也 是 一 样 。 在 山 赛 产品 流行 之 前 ， 假 货 也 是 比 
较 “ 盛 行 ? 的 。 本 人 2002 年 买 了 一 部 手机 ， 当 时 老板 吹 得 天 人 花 乱 险 ， 承 话 
这 部 手机 是 最 新 的 ， 我 看 肴 也 像 ， 元 子 是 轿 新 的 ， 包 装 是 细 新 的 ， 没 有 
任何 瑕 六 ， 束 是 比 正 品 便宜 了 很 多 ， 于 是 我 来 了 ， 因 为 缺 钱 啊 ! 用 了 3 
个 月 ， 坏 了 ， 送 修 检查 ， 结 果 诊 断 出 这 是 新 充 装 旧 机 ， 我 坚 ! 拿 一 部 旧 
手机 的 线路 板 ， 找 个 新 的 外 这 、 屏 幕 、 包 装 就 成 了 新 手机 ， 害 人 不 浅 
Mh! 

















我 们 不 说 不 开心 的 事情 ,今天 以 什么 例子 为 开场 白 昵 ?就 说 说 我 上 





小 学 的 粮 事 吧 。 我 上 小 学 的 时 候 学 习 成 绩 非 常 奢 ， 班 级 上 有 40 多 个 同 

学 ， 我 基本 上 都 是 排 在 45 名 以 后 ， 按 照 老 师 给 我 的 评价 就 是 :“ 不 是 读 
书 的 料 ”。 但 是 我 父 杀 管 得 很 严格 ， 明 知 着 我 不 是 这 块 料 ， 还 是 “ 赶 鸭 子 
上 以 ”， 每 次 考 完 试 我 都 战 项 项 , “人 竹 筋 炒 肉 ?是 肯定 少不了 的 ， 但 古 
能 少 点 就 少 点 吧 ， 因 为 肉 可 是 上 自己 的 。 四 年 级 期 末 考 试 考 完 ， 学 校 出 来 
个 很 损 的 招 儿 (这 招 儿 现在 很 流行 的 ) ， 打 印 出 成 绩 单 ， 要 家 长 签字 ， 

然后 才能 上 五 年 级 ， 我 那个 妨 惧 呀 ， 不 过 也 就 是 几 秒 钟 的 时 间 ， 玩 起 来 
什么 都 筷 记 了 。 我 们 做 架构 ， 做 设计 ， 任 何 值得 我 们 回忆 的 事件 都 可 以 
通过 设计 记录 下 来 。 当 然 了 ， 这 份 成 绩 单 的 事情 也 是 可 以 通过 类 图 表示 
的 ， 如 图 17-1 所 示 。 


















成 绩 单 有 两 个 方法 : 
report 描 述 成 缚 
Sign 要 家 长 签字 


SchoolReport 


+vold report() 
+Vold sign(String name) 





FouthGrade SchoolReport 
[| 


图 17-1 成 绩 单 类 图 





成 绩 单 的 抽象 类 ， 然 后 有 一 个 四 年 级 的 成 绩 单 实现 类 ，So Easy， 


我 们 先 来 看 抽象 类 ， 如 代码 清单 17-1 所 示 。 


代码 清单 17-1 抽象 成 绩 单 


public abstract class SchoolReport { 
// 成 绩 单 主要 展示 的 就 是 你 的 成 绩 情 况 
public abstract void report(); 
// 成 绩 单 要 家 长 签字 ， 这 个 是 最 要 命 的 
public abstract void sign(); 

















有 抽象 类 了 ， 我 们 再 来 看 看 具体 的 四 年 级 成 绩 单 
FouthGradeSchoolReport， 如 代码 清单 17-2 所 示 。 


代码 清单 17-2 四 年 级 成 绩 单 


public class FouthGradeSchoolReport extends SchoolReport { 
// 我 的 成 绩 单 
public void report() { 
// 成 绩 单 的 格式 是 这 个 样子 的 
System.out.println(" 尊 敬 的 XXX 家 长 :"); 
System.out .println(” ...... i 








System.out.println(" 语文 62 数学 65 体育 98 自然 ”63 
System.out.printilin(™" ....... 1) 
System,out.println(" 家 长 签名 : ") 
} 
// 家 长 签名 


public void sign(String name) { 
System.out.println(" 家 长 签名 为 : "+name ) ; 
} 


成 绩 单 出 来 ， 你 别 看 什么 62、65 之 类 的 成 绩 ， 你 要 知道 ， 在 小 学 低 
于 90 分 基本 上 就 是 中 下 等 了 ， 莫 表 呀 ， 爱 学 习 的 人 咋 就 那么 多 ! 怎么 
者 ， 那 我 把 这 个 成 绩 单 给 老公 看 看 ? 好 ， 我 们 修改 一 下 类 图 ， 成 绩 单 给 
老 爸 看， 如 图 17-2 所 示 。 


成 绩 单 有 两 个 方法 : 
report 描 述 成 绩 


sign 要 家 长 签字 










Father 


FouthGrade SchoolReport 


图 17-2 老区 查看 成 绩 单 类 图 








老 爸 开始 看 成 绩 单 ， 这 个 成 绩 单 可 是 最 真实 的 ， 啥 都 没有 动 过 ， 原 
装 ，Father 类 如 代码 清单 17-3 所 示 。 


代码 清单 17-3 老爷 伍 看 成 绩 E 


public class Father { 
public static void main(String[|] args) { 
// 把 成 绩 单 拿 过 来 
SchoolReport sr = new FouthGradeSchoolReport(); 
// 看 成 绩 单 
sr.report(); 
// 签 名 ? 休想 ! 


-一 


运行 结果 如 下 : 


尊敬 的 XXX 家 长 : 





家 长 签名 : 


就 这 成 绩 还 要 我 签字 ? ! 老公 了 束 开 始 找 扫 希 ， 我 开始 做 准备 : 深 呼 
吸 ， 绷 紧 肌 肉 ， 提 辟 收 腹 。 哈 哈 ， 竺 运 的 是 ， 这 个 不 是 当时 的 真实 情 
况 ， 我 没有 直接 把 成 绩 单 交 给 老 爸 ， 而 是 在 交 给 他 之 前 做 了 点 技术 工 
作 ， 我 要 把 成 绩 单 封装 一 下 ， 封 六 分 类 两 步 来 实现 ， 如 下 所 示 。 


e 汇 报 最 高 成 绩 


跟 老 色 说 各 个 科目 的 最 高 分 ， 语 文 最 高 是 5， 数 学 是 78， 目 然 是 
80， 然 后 老 冯 觉得 我 的 成 绩 与 最 高 分 数 相 兰 不 多 ， 考 的 还 是 不 错 的 嘛 ! 
这 个 是 实情 ， 但 是 不 知道 是 什么 原因 ， 上 反正 期 末 考 试 都 考 得 不 怎么 样 ， 
但 是 基本 上 都 集中 在 70 分 以 上 ， 我 这 60 多 分 基本 上 还 是 垫底 的 角色 。 








e 汇 报 排名 情况 


在 老 色 看 完成 绩 单 后 ， 千 诉 他 我 在 全 班 排 第 38 名 ， 这 个 也 是 实情 ， 
为 喻 呢 ?” 有 将 近 十 个 同学 退学 了 ! 这 个 情况 我 是 不 会 说 的 。 不 知道 是 不 
古 当时 第 一 次 友 成 绩 单 时 学 校 没有 考虑 消 楚 ， 没 有 写 上 总 共有 多 少 同 
学 ， 排 第 几 名 ， 肥 正 是 被 我 外 了 个 空子 。 





那 修饰 是 说 完了 ， 我 们 看 看 类 图 如 何 修 改 ， 如 图 17-3 所 示 。 


成 绩 单 有 两 个 方法 : 
report 描 述 成 绩 
sign 要 家 长 签字 +void report() 


SchoolReport 


+void sign(String name) 











FouthGrade SchoolReport 


四 年 级 的 成 绩 单 





SugarFouthGrade SchoolReport 






重 写 report 方 法 
先 调 用 两 个 私有 方法 -void reportHighScore() 
-Vold reportSort() 


Father 


+void report() 


图 17-3 修饰 成 绩 单 





我 想 这 是 大 家 最 容易 想到 的 类 图 ， 通 过 直接 增加 了 一 个 子 类 ， 重 写 
report 方 法 ， 很 容易 地 解决 了 这 个 问题 ， 是 不 是 这 样 ? 是 的 ， 这 确实 是 
一 个 比较 好 的 办 法 ， 我 们 来 看 具体 的 实现 ， 如 代码 清单 17-4 所 示 。 


代码 清单 17-4 修饰 成 绩 单 


public class SugarFouthGradeSchoolReport extends FouthGradeSchool 
// 首 先 要 定义 你 要 美化 的 方法 ， 先 给 老 爸 说 学 校 最 高 成 绩 
private void reportHighScore(){ 
System.out.println(" 这 次 考试 语文 最 高 是 75， 数 学 是 78， 自 然 是 


} 

// 在 老 爸 看 完毕 成 绩 单 后， 我 再 汇报 学 校 的 排名 情况 

private void reportSort(){ 
System.out.println(" 我 是 排名 第 38 名 ...")，; 


} 

// 由 于 汇报 的 内 容 已 经 发 生变 更 ， 那 所 以 要 重 写 父 类 
QOverride 

public void report(){ 





























this.reportHighScore(); // 先 说 最 高 成 绩 
super ,report(); // 然 后 老 爸 看 成 绩 单 
this,reportSort(); // 然 后 告诉 老 爸 学 习 学 校 排名 











然后 对 Father 类 稍 做 修改 就 可 以 看 到 美化 后 的 成 绩 单 ， 如 代码 清单 
17-5 所 示 。 


代码 清单 17-5 老区 查看 修饰 后 的 成 绩 单 


public class Father { 
public static void main(String[] args) { 

// 把 美化 过 的 成 绩 单 拿 过 来 
SchoolReport sr= new SugarFouthGradeSchooJLReport ( ) 
// 看 成 绩 单 
sr.report(); 
// 然 后 老将， 一 看 ， 很 开心 ， 就 签名 了 
sr,sSign(" 老 三 ")， // 我 叫 小 三 ， 老 爸 当 然 叫 老 三 


一 


运行 结果 如 下 所 示 : 





这 次 考试 语文 最 高 是 75， 数 学 是 78， 自 然 是 80 





尊敬 的 XXX 家 长 : 





我 是 排名 第 38 名 .… 
家 长 签名 为 : 老 三 


通过 继承 确实 能 够 解决 这 个 问题 ， 老 多 看 成 绩 单 很 开心 ， 然 后 就 给 
签字 了 ， 但 现实 的 情况 是 很 复杂 的 ， 可 能 老公 听 我 汇报 最 高 成 绩 后 ， 束 
直接 乐 开花 了 ， 直 接 签名 了 ， 后 面 的 排名 就 没 必 要 看 了 ， 或 者 老爷 要 先 
看 排名 情况 ， 那 怎么 办 ? 继续 扩展 ?你 能 扩展 多 少 个 类 ?这 还 是 一 个 比 
较 简 单 的 场景 ， 一 旦 需要 奢 饰 的 条 件 非常 多 ， 比 如 20 个 ， 你 还 通过 继承 
来 解决 ， 你 想象 的 子 类 有 多 少 个 ”你 是 不 是 马上 就 要 月 浊 了 ! 








好 ， 你 也 看 到 通过 继承 情况 确实 出 现 了 问题 ， 类 爆炸 ， 类 的 数量 激 
增 ， 光 写 这 些 类 不 烷 死 你 才 怪 ， 而 且 还 要 想 想 以 后 维护 怎么 办 ， 谁 愿意 
接收 这 么 一 大 挫 本 质 相 似 的 代码 维护 工作 ? 并且 在 面 辐 对 象 的 设计 中 ， 
如 果 超 过 两 层 继承 ， 你 就 应 该 想 想 是 不 是 出 设计 问题 了 ， 是 不 是 应 该 重 
新 找 一 条 康 庄 大 道 了 ， 这 是 经 验 值 ， 不 是 什么 绝对 的 ， 继 承 层次 越 多 以 
后 的 维护 成 本 越 多 ， 问 题 这 么 多 ， 那 上 怎么 办 ? 好 办 ， 我 们 定义 一 批 专门 
负责 装饰 的 类 ， 然 后 根据 实际 情况 来 决定 是 否 需要 进行 装饰 ， 类 图 稍 做 
修正 ， 如 图 17-4 所 示 。 
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图 17-4 增加 专门 的 装饰 类 图 


增加 一 个 抽象 类 和 两 个 实现 类 ， 其 中 Decorator 的 作用 是 封装 
SchoolReport 类 ， 如 果 大 家 还 记得 代理 模式 ， 那 么 很 容易 看 懂 这 个 类 
图 ， 装 饰 类 的 作用 也 就 是 一 个 特殊 的 代理 类 ， 真 实 的 执行 者 还 是 被 代理 
的 角色 FouthGradeSchoolReport， 如 代码 清单 17-6 所 示 。 


代码 清单 17-6 修饰 的 抽象 类 


public abstract class Decorator extends SchoolReport{ 
// 首 先 我 要 知道 是 哪个 成 绩 单 
private SchoolReport sr; 
// 构 造 函 数 ， 传 递 成 绩 单 过 来 


public Decorator(SchoolReport sr)t{ 








this.sr = sr; 


} 

// 成 绩 单 还 是 要 被 看 到 的 

public void report(){ 
this.sr.report(); 








} 

// 看 完 还 是 要 签名 的 

public void sign(String name)t{ 
this.sr.sign(name); 

} 





看 到 没 ， 装 饰 类 还 是 把 动作 的 执行 委托 给 需要 装饰 的 对 象 ， 
Decorator 抽 象 类 的 目的 很 简单 ， 束 是 要 让 子 类 来 封装 SchoolReport 的 子 
类 ， 怎 么 封装 ? 重 写 report 方 法 ! 先 看 HighScoreDecorator 实 现 类 ， 如 代 
码 清单 17-7 所 示 。 


代码 清单 17-7 最 高 成 绩 修 饰 


public class HighScoreDecorator extends Decorator { 
// 构 造 函 数 
public HighScoreDecorator(SchoolReport sr)t{ 
super (sr); 














} 
// 我 要 汇报 最 高 成 绩 
private void reportHighScore(){ 
System.out.println(" 这 次 考试 语文 最 高 是 75， 数 学 是 78， 自 然 是 


} 
// 我 要 在 老爷 看 成 绩 单 前 告诉 他 最 高 成 绩 ， 否 则 等 他 一 看 ， 就 抢 起 扫 蝇 接 我 ， 我 旦 
@Override 
public void report(){ 
this.reportHighSscore( ); 
super.report(); 














bs | 








重 写 了 report 方 法 ， 先 调用 具体 装饰 类 的 装饰 方法 reportHighScore， 
然后 再 调用 具体 构件 的 方法 ， 我 们 再 来 看 怎么 汇报 学 校 排序 情况 





SortDecorator 代 码 ， 如 代码 清单 17-8 所 示 。 


代码 清单 17-8 排名 情况 修饰 


public class SortDecorator extends Decorator { 
// 构 造 函数 
public SortDecorator(SchoolReport sr)t{ 
super (sr); 


} 

// 告 诉 老爷 学 校 的 排名 情况 

private void reportSort(){ 
System.out.println(" 我 是 排名 第 38 名 ...")， 


} 
// 老 爸 看 完成 绩 单 后 再 告诉 他 ， 加 强 作 用 
Q@override 
public void report(){ 
super .report( ); 
this.reportSort( ); 








ww 





我 准备 好 了 这 两 个 强力 的 修饰 工具 ， 然 后 束 “ 坚 不 藤 惧 ”地 把 成 绩 上 
交 给 老 冯 ， 看 看 老公 怎么 看 成 绩 单 的 ， 如 代码 清单 17-9 所 示 。 


代码 清单 17-9 老 和 爸 查 看 修饰 后 的 成 绩 E 


public class Father { 
public static void main(String[|] args) { 

// 把 成 绩 单 拿 过 来 
SchoolReport sr; 
// 原 装 的 成 绩 单 
sr = new FouthGradeSchoolReport(); 
// 加 了 最 高 分 说 明 的 成 绩 单 
sr = new HighScoreDecorator(sr); 
// 义 加 了 成 台 贡 排 名 的 说 明 
sr = new SortDecorator(sr); 
// 看 成 绩 单 
sr.report(); 
// 然 后 老 爸 一 看 ， 很 开心 ， 就 签名 了 
sr.sign(" 老 三 ")， // 我 叫 小 三 ， 老 和 爸 当 然 叫 老 三 





老区 一 看 成 绩 单 ， 听 我 这 么 一 说 ， 非 第 开心 ， 儿 子 有 进步 呀 ， 从 40 
多 名 进步 到 30 多 名 ， 进 步 很 大 ， 纵 过 了 一 顿 海 届 。 想 想 看 ， 如 果 我 还 要 
增加 其 他 的 修饰 条 件 ， 是 不 是 就 非常 容易 了 ， 只 要 实现 Decorator 类 就 可 
以 了 ! 这 就 是 装饰 模式 。 








17.2 北 饰 模式 的 定义 


装饰 模式 (Decorator Pattern ) 是 一 种 比较 常见 的 模式 ， 其 定义 如 
下 : Attach additional responsibilities to an object dynamically keeping the 
same interface.Decorators provide a flexible alternative to subclassing for 
extending functionality.《〈 动 态 地 给 一 个 对 象 添加 一 些 额外 的 职 贡 。 就 增 
加 功能 来 说 ， 装 饰 模式 相 比 生成 子 类 更 为 灵活 。) 


装饰 模式 的 通用 类 图 如 图 17-5 所 示 。 
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图 17-5 装饰 模式 的 通用 类 图 

在 类 图 中 ， 有 四 个 角色 需要 说 明 : 

e Component 抽 象 构件 


Component 是 一 个 接口 或 者 是 抽象 类 ， 束 是 定义 我 们 最 核心 的 对 
象 ， 也 就 是 最 原始 的 对 象 ， 如 上 面 的 成 绩 单 。 





注意 ”在 装饰 模式 中 ， 必 然 有 一 个 最 基本 、 最 核心 、 最 原始 的 接 


口 或 抽象 类 充当 Component 抽 象 构件 。 


e ConcreteComponent 具体 构件 


ConcreteComponent 是 最 核心 、 最 原始 、 最 基本 的 接口 或 抽象 类 的 
实现 ， 你 要 装饰 的 就 是 它 。 


e@ Decorator 装 饰 角 色 
一 般 是 一 个 抽象 类 ， 做 什么 用 呢 ?” 实 现 接 口 或 者 抽象 方法 ， 它 里 面 


可 不 一 定 有 抽象 的 方法 呀 ， 在 它 的 属性 里 必然 有 一 个 private 变 量 指 辐 
Component 抽 象 构件 。 


e 具体 装饰 角色 


ConcreteDecoratorA 和 ConcreteDecoratorB 是 两 个 具体 的 装饰 类 ， 你 
要 把 你 最 核心 的 、 最 原始 的 、 最 基本 的 东西 装饰 成 其 他 东西 ， 上 面 的 例 
子 就 是 把 一 个 比较 平庸 的 成 绩 单 装饰 成 家 长 认可 的 成 绩 上 


装饰 模式 的 所 有 角色 都 已 经 解释 完毕 ， 我 们 来 看 看 如 何 实现 ， 先 看 
抽象 构件 ， 如 代码 清单 17-10 所 示 。 


代码 清单 17-10 抽象 构件 


public abstract class Component { 
// 抽 象 的 方法 
public abstract void operate( ) ; 





具体 构件 如 代码 清单 17-11 所 示 。 


代码 清单 17-11 具体 构件 


public class ConcreteComponent extends Component { 
// 具 体 实现 
@Override 
public void operate() { 
System.out.println("do Something"); 


装饰 角色 通常 是 一 个 抽象 类 ， 如 代码 清单 17-12 所 示 。 


代码 清单 17-12 抽象 装饰 者 


public abstract class Decorator extends Component { 
private Component component = null; 
// 通 过 构造 函数 传递 被 修饰 者 
public Decorator(Component _component)t{ 
this.component = _component; 


} 

// 委 托 给 被 修饰 者 执行 

@Override 

public void operate() { 
this.component.operate( ); 

} 








当然 了 ， 知 只 有 一 个 装饰 类 ， 则 可 以 没有 抽象 装饰 角色 ， 直 接 实现 
具体 的 逆 饰 角色 即 可 。 有 具体 的 装饰 类 如 代码 清单 17-13 所 示 。 
代码 清单 17-13 具体 的 装饰 类 


public class ConcreteDecorator1 extends Decorator { 
// 定 义 被 修饰 者 








public ConcreteDecorator1(Component _component ){ 
Super(_component ) ; 


} 

// 定 义 自己 的 修饰 方法 

private void method1(){ 
System.out.println("method1 修饰 "); 





} 

// 重 写 父 类 的 0peration 方 法 

public void operate(){ 
this.method1( ); 
super .operate( ) ; 


} 


public class ConcreteDecorator2 extends Decorator { 
// 定 义 被 修饰 者 
public ConcreteDecorator2(Component _component ){ 
super(_component); 


} 

// 定 义 自己 的 修饰 方法 

private void method2()t{ 
System.out.println("method2 修 饰 ")， 





} 

// 重 写 父 类 的 0peration 方 法 

public void operate(){ 
super ,operate( ) ; 
this.method2( ); 





注意 ”原始 方法 和 装饰 方法 的 执行 顺序 在 具体 的 装饰 类 是 固定 
的 ， 可 以 通过 方法 重 载 实现 多 种 执行 顺序 。 














我 们 通过 Client 类 来 模拟 高 层 模块 的 耦合 关系 ， 看 看 装饰 模式 是 如 
何 运 行 的 ， 如 代码 清单 17-14 所 示 。 


代码 清单 17-14 场景 类 


public class Client { 
public static void main(String[] args) { 


Component component = new ConcreteComponent(); 
// 第 一 次 修饰 
component = new ConcreteDecoratori(component); 
// 第 二 次 修饰 
component = new ConcreteDecorator2(component); 
// 修 饰 后 运行 
component .operate( ); 





17.3 涂饰 模式 应 用 


17.3.1 装饰 模式 的 优点 


e 装饰 类 和 被 装饰 类 可 以 独立 发 展 ， 而 不 会 相互 丰 合 。 换 句 话 说 ， 
Component 类 无 须知 道 Decorator 类 ，Decorator 类 是 从 外 部 来 扩展 


Component 类 的 功能 ， 而 Decorator 也 不 用 知道 具体 的 构件 。 


e 装饰 模式 是 继承 关系 的 一 个 将 代 方 案 。 我 们 看 装饰 类 Decorator， 
不 管 装饰 多 少 层 ， 返 回 的 对 象 还 是 Component， 实 现 的 还 是 is-a 的 关系 。 





e 装饰 模式 可 以 动态 地 扩展 一 个 实现 类 的 功能 ， 这 不 需要 多 说 ， 装 
饰 模式 的 定义 束 是 如 此 。 


17.3.2 装饰 模式 的 缺点 


对 于 装饰 模式 记 住 一 点 就 足够 了 : 多 层 的 装饰 是 比较 复杂 的 。 为 什 
么 会 复杂 了 呢 ? 你 想 想 看 ， 就 像 剥 洋 芍 一样， 你 剥 到 了 最 后 才 发 现 是 最 里 
层 的 奢 饰 出 现 了 问题 ， 想 象 一 下 工作 量 吧 ， 因 此 ， 尽 量 减少 装饰 类 的 数 
量 ， 以 便 降 低 系 统 的 复杂 上 度 。 


17.3.3 装饰 模式 的 使 用 场景 


e 需要 扩展 一 个 类 的 功能 ， 或 给 一 个 类 增加 附加 功能 。 


。 需要 动态 地 给 一 个 对 象 增加 功能 ， 这 些 功能 可 以 再 动态 地 撤销 。 


e 需要 为 一 批 的 兄 第 类 进行 改装 或 加 闭 功 能 ， 当 然 是 首选 装饰 模 
式 。 


17.4 最 佳 实践 


凌 饰 模式 是 对 继承 的 有 力 补充 。 你 要 知道 继承 不 是 万 能 的 ， 继 承 可 
以 解决 实际 的 问题 ， 但 是 在 项 目 中 你 要 考虑 诸如 易 维 护 、 易 扩展 、 易 复 
用 等 ， 而 且 在 一 些 情 况 下 《比如 上 面 那个 成 绩 单 例子 ) 你 要 是 用 继承 就 
会 增加 很 多 子 类 ， 而 且 灵 活性 非常 赤 ， 那 当然 维护 也 不 容易 了 ， 也 惑 是 
说 逆 饰 模式 可 以 蔡 代 继承 ， 解 决 我 们 类 膨胀 的 问题 。 同 时 ， 你 还 要 知道 
继承 是 静态 地 给 类 增加 功能 ， 而 装饰 模式 则 是 动态 地 增加 功能 ， 在 上 面 
的 那个 例子 中 ， 我 不 想 要 SortDecorator 这 层 的 封装 也 很 简单 ， 于 是 直接 
在 Father 中 去 掉 就 可 以 了 ， 如 果 你 用 继承 就 必须 修改 程序 。 

















装饰 模式 还 有 一 个 非常 好 的 优点 : 扩展 性 非常 好 。 在 一 个 项 目 中 ， 
你 会 有 非常 多 的 因素 考虑 不 到 ， 特 别 是 业务 的 变更 ， 不 时 地 冒 出 一 个 需 
求 ， 尤 其 是 提出 一 个 令 项 目 大 量 延 迟 的 需求 时 ， 那 种 心情 是 相当 的 难 
受 ! 装饰 模式 可 以 给 我 们 很 好 的 帮助 ， 通 过 装饰 模式 重新 封装 一 个 类 ， 
而 不 是 通过 继承 来 完成 ， 人 简单 点 说 ， 三 个 继承 关系 Father、Son、 
GrandSon 三 个 类 ， 我 要 在 Son 类 上 增强 一 些 功 能 怎么 办 ? 我 想 你 会 坚决 
地 项 回去 ! 不 允许 ， 对 了 ， 为 什么 呢 ? 你 增强 的 功能 是 修改 Son 类 中 的 
方法 吗 ? 增加 方法 吗 ? 对 GrandSon 的 影响 呢 ? 特别 是 GrandSon 有 多 个 的 
情况 ， 你 会 怎么 办 ? 这 个 评估 的 工作 量 就 够 你 受 的 ， 所 以 这 是 不 允许 


的 ， 那 还 是 要 解雇 问题 的 呀 ， 怎 么 办 ?” 通过 建立 SonDecorator 类 来 修饰 

















Son， 相 当 于 创建 了 一 个 新 的 类 ， 这 个 对 原 有 程序 没有 变更 ， 通 过 扩展 
很 好 地 完成 了 这 次 变更 。 


第 18 章 “” 生 略 模式 


18.1 刘备 江东 娶 妻 ， 赵 云 他 容易 吗 


在 三 国 演义 中 ， 我 最 佩服 诸 匈 亮 的 地 方 不 是 因为 他 未 出 第 亡 而 有 三 
分 天 下 的 预测 ， 也 不 是 他 在 赤壁 麻 战 中 借 东 风 的 法 术 ， 更 不 是 他 七 擒 七 
纵 坪 获 的 全 略 。 那 是 什么 呢 ? 是 他 “ 气 死 周 瑜 ， 吕 死 王 表 ” 的 气度 和 风 
范 ! 想 想 看 ， 你 用 “ 气 ” 能 把 一 个 轮胎 打炮 ， 用 “ 气 ” 枪 能 够 把 路 灯 打 伴 ， 
但 是 要 把 跟 你 没有 任何 血缘 关系 的 人 气 死 有 多 困难 呀 ， 更 何况 是 周瑜 这 
种 智慧 型 人 物 ! 


在 诺 允 亮 气 周瑜 的 过 程 中 ， 有 一 件 事 情 : 那 就 是 周瑜 赔 了 夫人 又 折 
兵 这 件 事情 。 事 情 经 过 是 这 样 的 : 孙权 看 刘备 有 雄 起 之 意 ， 杀 是 不 能 杀 
了 ， 那 会 都 天 下 人 唾弃 ， 就 想 个 招 儿 挫 他 一 下 ， 那 有 什么 办 法 呢 ? 孙权 
有 个 妹妹 一 一 孙 尚 香 ， 准 备 招 刘备 做 女 婚 ， 然 后 孙权 想 办 法 把 刘备 软 茶 
起 来 ， 孙 权 的 想法 还 是 很 单纯 的 咏 ， 就 是 不 让 你 刘备 回 西川 ， 然 后 我 东 
吴 想 干 喻 就 干 喻 ， 夺 荆州 ， 否 西川 也 不 是 不 可 能 的 。 东 美的 想法 是 好 
的 ， 无 共 中 间 多 了 乔 诬 无 敌 的 诸 太 完 ， 他 早 束 预测 了 东 吴 有 此 招数 ， 于 
是 在 刘备 去 东 吴 招 羔 之 前 ， 特 授 以 伴 即 赵云 三 个 锦 陡 ， 说 是 按 天 机 拆 开 
解决 棘手 问题 。 




















这 三 个 妙计 分 别 是 : 找 乔 国 老 帮 忙 〈 也 就 是 走后门 了 ) ， 求 吴 国 太 
放行 “ 诉 杏 ) 以 及 孙 夫 人 断后 ， 对 这 三 个 妙计 不 熟悉 的 读者 可 以 去 温习 
一 下 《三 国 演 义 》， 这 里 就 不 多 说 了 。 想 想 看 ， 这 三 个 计谋 有 什么 相似 
之 处 ， 他 们 都 是 告诉 赵云 要 怎么 执行 ， 也 就 是 说 这 三 个 计谋 都 有 一 个 方 
法 是 执行 ， 具 体 执行 什么 内 容 ， 每 个 计谋 当然 不 同 了 ， 分 析 到 这 里 ， 我 
们 是 不 是 就 有 这 样 一 个 设计 思路 : 三 个 妙计 应 该 实现 的 是 同一 个 接口 ? 
聪明 ! 是 的 ， 我 们 来 看 类 图 ， 如 图 18-1 所 示 。 
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图 18-1 三 个 策略 类 图 


找 乔 国 老 开 后 门 





这 是 非常 简单 的 类 图 ， 在 这 个 场景 中 的 三 个 主要 角色 都 已 经 有 了 ， 
每 个 妙计 都 提供 了 一 个 可 执行 的 方法 ， 我 们 先 来 看 接口 ， 如 代码 清单 


18-1 所 示 。 


代码 清单 18-1 妙计 接口 


public interface IStrategy { 
// 每 个 锅 吉 妙 计 都 是 一 个 可 执行 的 算法 
public void operate(); 














接口 很 简单 ， 定 义 了 一 个 方法 operate， 每 个 妙计 都 是 可 执行 的 ， 否 
则 那 叫 什 么 妙计 ， 我 们 先 看 第 一 个 妙计 一 一 找 乔 国 老 开 后 门 ， 如 代码 清 
单 18-2 所 示 。 


代码 清单 18-2 乔 国 老 开 后 门 


public class BackDoor implements IStrategy { 
public void operate() { 
System.out.println(" 找 乔 国 老 帮 忙 ， 让 吴 国 太 给 孙权 施加 压力 ") 
} 











第 二 个 妙计 是 找 吴 国 太 峰 诉 ， 企 图 给 上 自己 开绿灯 ， 如 代码 清单 18-3 
所 示 。 
代码 清单 18-3 吴 国 太 开绿灯 


public class GivenGreenLight implements IStrategy { 
public void operate() { 
System,out.printLn(" 求 吴 国 太 开绿灯 ,放行 ! ")， 
} 


三 个 妙计 是 在 逃跑 的 时 候 ， 证 新 奶子 孙 夫 人 断后 ， 谁 来 砍 谁 ， 这 


是 非常 好 的 主意 ， 如 代码 清单 18-4 所 示 。 


代码 清单 18-4 孙 夫 人 断后 


public class BlockEnemy implements IStrategy { 
public void operate() { 
System.out.println(" 孙 夫人 断后 ， 挡 住 追 兵 ")， 
} 





在 这 个 场景 中 ， 三 个 妙计 都 有 了 ， 那 还 缺少 两 个 配角 : 第 一 ， 妙 计 
肯定 要 帮 到 一 个 地 方 吧 ， 这 么 重要 的 东西 要 保管 串 ， 也 就 是 承 装 妙 计 的 
锦 吉 ， 所 以 俗称 锦 宫 妙计 嘛 ; 第 二 ， 这 些 妙计 都 要 有 一 个 执行 人 吧 ， 是 
谁 ? 当然 是 赵云 了 ， 妙 计 是 小 之 给 的 ， 执 行者 是 赵云 。 赵 云 就 是 一 个 干 
活 的 人 ， 从 锦 守 中 取出 妙计 ， 执 行 ， 然 后 获胜 。 过 程 非常 清晰 ， 我 们 把 
完整 的 过 程 设 计 出 来 ， 如 图 18-2 所 示 。 


在 类 图 中 增加 了 一 个 Context 封 六 类 也 就 是 锦 守 ) ， 其 作用 是 承 装 
三 个 策略 ， 方 便 赵 云 使 用 ， 我 们 来 看 Context 代 码 ， 如 代码 清单 18-5 所 


钞 。 
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图 18-2 完整 类 图 





代码 清单 18-5 锦 襄 


public class Context { 

// 构 造 函 数 ， 你 要 使 用 哪个 妙计 

private IStrategy Straegy 

public Context(IStrategy strategy)t{ 
this.straegy = strategy; 


} 

// 使 用 计谋 了 ， 看 我 出 招 了 

public void operate(){ 
this.straegy.operate( ); 


$ 





通过 构造 浮 数 把 集 略 传递 进来 ， 然 后 用 operate() 方 法 来 执行 相关 的 





全 略 方法 。 三 个 妙计 有 了 ， 锦 时 也 有 了， 然后 就 是 赵云 雄 趟 趟 地 括 着 三 
个 锦 宫 ， 拉 着 已 步 入 老年 行列 的 、 还 想 着 娶 纯 情 少女 的 刘 老 爷 子 去 入 歼 
了 。 虽 ， 还 别 说 ， 小 腕 同志 的 三 个 妙计 还 真是 不 错 ， 如 代码 清单 18-6 所 


钞 。 





代码 清单 18-6 使 用 计谋 


public class ZhaoYun { 

// 赵 云 出 场 了 ， 他 根据 诸葛 亮 给 他 的 交代 ， 依 次 拆 开 妙计 

public static void main(String[] args) { 
Context context 
// 刚 刚 到 吴 国 的 时 候 拆 第 一 个 
System.out.println("--- 刚 刚 到 吴 国 的 时 候 拆 第 一 个 ---")， 
context = new Context(new BackDoor()); // 拿 到 妙计 
context.operate(); // 拆 开 执 行 
System.out .println("\nxnxnxnxXnxnxnxn” ) ; 
// 刘 备 乐 不 思 唱 了 ， 拆 第 二 个 了 
System,out ， pFintln("-- -刘备 乐 不 思 史 了 ， 拆 第 二 个 了 ---"); 
context = new Context(new GivenGreenLight()); 
context.operate(); // 执 行 了 第 二 个 锦 夺 
System.out.println("\n n\nN Nn\NnN NN\N"); 
// 和 孙权 的 小 兵 退 来 了 ， 咱 办? 拆 第 三 
System,out,printlLln("--- 孙 权 的 小 兵 追 来 了 ， 咋 办 ? 拆 第 三 个 --. 
context = new Context(new BlockEnemy( ) ) ; 
context.operate(); // 孙 夫人 退兵 
System.out .println(" nxnxnxnxXnxnxNnxn” ) ; 

















我 们 来 看 看 这 段 故 事 ， 运 行 结 果 如 下 : 





一 刚刚 到 吴 国 的 时 候 拆 第 一 个 --- 





找 乔 国 老 帮忙 ， 让 吴 国 太 给 孙权 施加 压力 
-刘备 乐 不 思 罚 了 ， 拆 第 二 个 --- 


求 吴 国 太 开 个 绿灯 ， 放 行 ! 





--- 孙 权 的 小 兵 妃 来 了 ， 咋 办 ? 拆 第 三 个 --- 











孙 夫 人 断后 ， 挡 住 退 兵 





恩 ， 不 错 ， 就 这 三 招 ， 搞 得 孙权 是 “ 赔 了 夫人 又 折 兵 "。 那 我 们 描述 
这 个 故事 的 过 程 就 是 策略 模式 。 





18.2 策略 模式 的 定义 


策略 模式 (Strategy Pattern ) 是 一 种 比较 简单 的 模式 ， 也 叫做 政策 


模式 (Policy Pattern) 。 其 定义 如 下 : 


Define a family of algorithms,encapsulate each one,and make them 
interchangeable. (定义 一 组 算法 ， 将 每 个 算法 都 封装 起 来 ， 并 且 使 它们 
之 间 可 以 互 换 。) 





这 个 定义 是 非常 明确 、 清 晰 的 , “定义 一 组 算法 ”， 看 看 我 们 的 三 个 
计谋 是 不 是 三 个 算法 ?“ 将 每 个 算法 都 封 厂 起来"， 封 装 类 Context 不 就 是 
这 个 作用 吗 ?“ 使 它们 可 以 互 换 ?当然 可 以 互 换 了 ， 都 实现 是 相同 的 接 
口 ， 那 当然 可 以 相互 转化 了 。 我 们 看 看 宋 略 模式 的 通用 类 图 ， 如 网 18-3 
所 示 。 




















十 Strategy 
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ConcreteStrategy 


图 18-3 策略 模式 通用 类 图 


策略 模式 使 用 的 就 是 面向 对 象 的 继承 和 多 态 机 制 ， 非 常 容易 理解 和 
掌握 ， 我 们 再 来 看 看 集 略 模式 的 三 个 角色 : 


e Context 封 装 角 色 








它 也 叫做 上 下 文 角色 ， 起 承上启下 封装 作用 ， 屏 菩 高 层 模块 对 入 
略 、 算 法 的 直接 访问 ， 封 装 可 能 存在 的 变化 。 





e Strategy 抽 象 策 略 角 色 


策略 、 算 法 家 族 的 抽象 ， 通 利 为 接口 ， 定 义 每 个 策略 或 算法 必须 具 
有 的 方法 和 属性 。 各 位 看 官 可 能 要 问 了 ， 类 图 中 的 AlgorithmInterface 是 
什么 意思 ， 嘿 嘿 ，algorithm 是 “运算 法 则 ”的 意思 ， 结 合 起 来 意思 就 明白 


了 吧 。 








e ConcreteStrategy 有 具体 策略 角色 
实现 抽象 策略 中 的 操作 ， 该 类 含有 有 具体 的 算法 。 


我 们 再 来 看 策略 模式 的 通用 源码 ， 非 常 简单 。 先 看 抽象 策略 角色 ， 
它 古 一 个 非常 普通 的 接口 ， 在 我 们 的 项 目 中 束 古 一 个 普通 得 不 能 再 普通 
的 接口 了 ， 定 义 一 个 或 多 个 具体 的 算法 ， 如 代码 清单 18-7 所 示 。 








代码 清单 18-7 抽象 的 策略 角色 


public interface Strategy { 
// 策 略 模式 的 运算 法 则 
public void doSomething() 





具体 策略 也 是 非常 普通 的 一 个 实现 类 ， 只 要 实现 接口 中 的 方法 就 可 
以 ， 如 代码 清单 18-8 所 示 。 





代码 清单 18-8 具体 策略 角色 


public class ConcreteStrategy1L implements Strategy { 
public void doSomething() { 
System.out.println(" 具 体 策略 1 的 运算 法 则 " )， 





} 
public class ConcreteStrategy2 implements Strategy { 
public void doSomething() { 
System.out.println(" 具 体 策略 2 的 运算 法 则 " )， 
} 








策略 模式 的 重点 就 是 封装 角色 ， 它 是 借用 了 代理 模式 的 思路 ， 大 家 
可 以 想 想 ， 它 和 代理 模式 有 什么 差别 ， 差 别 就 是 策略 模式 的 封装 角色 和 





被 封装 的 策略 类 不 用 是 同一 个 接口 ， 如 果 是 同一 个 接口 那 就 成 为 了 代理 
模式 。 我 们 来 看 封装 角色 ， 如 代码 清单 18-9 所 示 。 


代码 清单 18-9 封装 角色 


public class Context { 
// 抽 象 策略 
private Strategy strategy = null; 
// 构 造 函 数 设置 具体 策略 
public Context(Strategy _strategy)t{ 
this.strategy = _strategy; 


} 

// 封 装 后 的 策略 方法 

public void doAnythinig()t{ 
this.strategy.doSomething(); 

} 





高 层 模 块 的 调用 非常 简单 ， 知 道 要 用 哪个 策略 ， 产 生出 它 的 对 象 ， 
然后 放 到 封装 角色 中 就 完成 任务 了 ， 如 代码 清单 18-10 所 示 。 


代码 清单 18-10 高 层 模块 


public class Client { 
public static void main(String[|] args) { 

// 声 明 一 个 具体 的 策略 
Strategy strategy = new ConcreteStrategy1( ) 
// 声 明 上 下 文 对 象 
Context context = new Context(strategy); 
7// 执 行 封装 后 的 方法 
context.doAnythinig(); 








策略 模式 就 是 这 么 简单 ， 偷 着 乐 吧 ， 它 就 是 采用 了 面向 对 象 的 继承 
和 多 态 机 制 ， 其 他 没什么 玄机 。 想 想 看 ， 你 真实 的 业务 环境 有 这 人 么 简单 








吗 ? 一 个 类 实现 多 个 接口 很 正常 ， 你 要 有 火眼金睛 看 清楚 哪个 接口 是 抽 
象 集 略 接 口 ， 哪 些 是 和 策略 模式 没有 任何 关系 ， 这 束 是 你 作为 系统 分 析 
师 的 价值 所 在 。 





18.3 策略 模式 的 应 用 


18.3.1 策略 模式 的 优点 


e 算法 可 以 自由 切换 








这 是 集 略 模式 本 里 定义 的 ， 只 要 实现 抽象 策略 ， 它 就 成 为 策略 家 族 
的 一 个 成 员 ， 通 过 封装 角色 对 其 进行 封装 ， 保 证 对 外 提供 “可 自由 切 
换 ” 的 策略 。 


e 避免 使 用 多 重 条 件 判断 


如 末 没 有 集 略 模式 ， 我 们 想 想 看 会 是 什么 样子 ? 一 个 策略 家 族 有 5 
个 稼 略 算 法 ， 一 会 要 使 用 A 策 略 ， 一 会 要 使 用 B 策 略 ， 怎 么 设计 呢 ? 使 
用 多 重 的 条 件 语 句 ? 多 重 条 件 语句 不 易 维护 ， 而 且 出 错 的 概率 大 大 增 
强 。 使 用 集 略 模式 后 ， 可 以 由 其 他 模块 决定 采用 何 种 集 略 ， 集 略 家 族 对 
外 提供 的 访问 接口 束 是 封装 类 ， 简 化 了 操作 ， 同 时 避免 了 条 件 语 句 判 
哮 |。 


e 扩展 性 良好 


这 甚至 都 不 用 说 是 它 的 优点 ， 因 为 它 太 明显 了 。 在 现 有 的 系统 中 增 
加 一 个 策略 太 容易 了 ， 只 要 实现 接口 就 可 以 了 ， 其 他 都 不 用 修改 ， 类 似 











于 一 个 可 反复 拆 印 的 插件 ， 这 大 大 地 符合 了 OCP 原 则 ，。 


18.3.2 策略 模式 的 缺 反 


每 一 个 策略 都 是 一 个 类 ， 复 用 的 可 能 性 很 小 ， 类 数量 增多 。 





。 所 有 的 策略 类 都 需要 对 外 暴露 


YY 


上 层 模 块 必须 知道 有 哪些 集 略 ， 然 后 才能 决定 使 用 哪 一 个 琐 略 ， 这 
与 迪 米 特 法 则 是 相 违 背 的 ， 我 只 是 想 使 用 了 一 个 策略 ， 我 赁 什么 就 要 了 
解 这 个 策略 呢 ? 那 要 你 的 封闭 类 还 有 什么 意义 ? 这 是 原装 策略 模式 的 一 
个 缺点 ， 幸 运 的 是 ， 我 们 可 以 使 用 其 他 模式 来 修正 这 个 缺陷 ， 如 工 广 方 








法 模式 、 代 理 模 式 或 享 元 模式 。 
18.3.3 策略 模式 的 使 用 场景 
e@ 多 个 类 只 有 在 算法 或 行为 上 稍 有 不 同 的 场景 。 


e 算法 需要 目 由 切换 的 场景 。 


例如 ， 算 法 的 选择 是 由 使 用 者 决定 的 ， 或 者 算法 始终 在 进化 ， 特 别 
古 一 些 站 在 技术 前 沿 的 行业 ， 连 业务 专家 都 无 法 给 你 保证 这 样 的 系统 规 








则 能 够 存在 多 长 时 间 ， 在 这 种 情况 下 策略 模式 是 你 最 好 的 助手 。 


e 需要 屏 菩 算法 规则 的 场景 。 





现在 的 科技 发 展 得 很 快 ， 人 脑 的 记忆 是 有 限 的 (就 目前 来 说 是 有 限 
的 ) ， 太 多 的 算法 你 只 要 知道 一 个 名 字 就 可 以 了 ， 传 递 相 关 的 数字 进 
来 ， 反 馈 一 个 运算 结果 ， 万 事 大 吉 。 





18.3.4 策略 模式 的 注意 事项 


如 果 系 统 中 的 一 个 集 略 家 族 的 具体 集 略 数 量 超 过 4 个 ， 则 需要 考虑 
使 用 混合 模式 ， 解 决策 略 类 膨胀 和 对 外 暴露 的 问题 ， 否 则 日 后 的 系统 维 
护 就 会 成 为 一 个 次 手 山 六 ， 谁 都 不 想 接 。 





18.4 策略 模式 的 扩展 


先 给 出 一 道 小 学 的 题目 : 输入 3 个 参数 ， 进 行 加 减法 运算 ， 参 数 中 
两 个 是 int 型 的 ， 剩 下 的 一 个 参数 是 String 型 的 ， 只 有 “+”、“-” 两 个 符号 可 
以 选择 ， 不 要 考虑 什么 复杂 的 校 验 ， 我 们 做 的 是 白 箱 测试 ， 输 入 的 就 是 
标准 的 int 类 型 和 合 规 的 String 类 型 ， 各 位 大 侠 ， 想 想 看 ， 怎 么 做 ， 简 单 


得 很 ! 





有 非常 多 的 实现 方式 ， 我 今天 来 说 四 种 。 先 说 第 一 种 ， 写 一 个 类 ， 
然后 进行 加 减法 运算 ， 类 图 也 不 用 画 了 ， 太 简单 了 ， 如 代码 清单 18-11 
所 示 。 





代码 清单 18-11 最 直接 的 加 减法 


public class Calculator { 


// 加 符号 
private final static String ADD_ SYMBOL = "+"， 
// 减 符号 
private final static String SUB_ SYMBOL = "-"， 


public int exec(int a,int b,String symbol)t{ 
int result =0; 
if(symbol.equals(ADD_SYMBOL)){ 
result = this.add(a, b); 
}else if(symbol.equals(SUB_ SYMBOL))E{ 
result = this.sub(a, b); 


return result; 
} 
// 加 法 运算 


private int add(int a,int b)t{ 
return a+b; 
} 





// 减 法 运算 

private int sub(int a,int b)t{ 
return a-b; 

} 


算法 太 简 单 了 ， 每 个 程序 员 都 会 写 。 再 写 一 个 场景 类 如 18-12 所 


代码 清单 18-12 场景 类 


public class Client { 
public static void main(String[] args) { 


// 输 入 的 两 个 参数 是 数字 
int a = Integer.parseIint(args[0|); 


AI 


String Symbol = args[1]; // 付 与 

int b = Integer.parseIint(args[2]); 
System,out,println(" 输 入 的 参数 为 : "+Arrays.toString(art 
// 生 成 一 个 运算 器 

Calculator cal = new Calculator(); 
System,out.printlLn(" 运 行 结果 为 : "+a + Symbol + b + "=" 





输入 3 个 参数 ， 分 别 是 100 + 200， 运 行 结果 如 下 所 示 : 


输入 的 参数 为 : [100, +, 200] 


运行 结果 为 : 100+200=300 











I 


这 个 方案 是 非常 简单 的 ， 能 够 解决 问题 ， 我 相信 这 是 大 家 最 容易 想 
到 的 方案 ， 我 们 不 评论 这 个 方案 的 优 劣 ， 等 把 四 个 方案 全 部 讲 完 了 ， 你 
目 己 就 会 发 现 熟 优 辑 劣 。 





我 们 再 来 看 第 二 个 方案 ，Calculator 类 太 叶 了 ， 简 化 算法 如 代码 清单 


18-13 所 示 。 


代码 清单 18-13 简化 算法 


public class Calculator { 


// 加 符号 
private final static String ADD_SYMBOL = "+"”; 
// 减 符号 
private final static String SUB_ SYMBOL = "-"， 


public int exec(int a,int b,String Symbol){ 
return symbol.equals(ADD_SYMBOL)?a+b:a-b; 
} 


这 也 非常 简单 ， 就 是 一 个 三 目 运 算 符 ， 确 实 简 化 了 很 多 。 有 缺陷 移 
别管 ， 我 们 主要 讲 设 计 ， 你 在 实际 项 目 应 用 中 要 处 理 该 程序 中 的 缺陷 。 


该 方案 的 场景 类 与 方 采 一 相同 ， 如 代码 清单 18-12 所 示 ， 运 行 结果 
也 相同 ， 不 再 资 述 。 


我 们 再 来 思考 第 三 个 方案 ， 本 章 介 绍 策略 模式 ， 那 把 策略 模式 应 用 
到 该 需求 是 不 是 很 合适 啊 ? 是 的 ， 非 常 合适 ! 加 减法 就 是 一 个 具体 的 策 
略 ， 非 常 简单 ， 省 略 类 图 ， 直 接 看 源码 ， 我 们 先 来 看 抽象 策略 ， 定 义 每 
个 策略 必须 实现 的 方法 ， 如 代码 清单 18-14 所 示 。 











代码 清单 18-14 引入 策略 模式 


interface Calculator { 
public int exec(int a,int b); 


抽象 策略 定义 了 一 个 唯一 的 方法 来 执行 运算 。 全 于 有 具体 执行 的 是 加 


法 还 是 减法 ， 运 算 时 由 上 下 文 角色 决定 。 我 们 再 来 看 两 个 具体 的 策略 ， 
如 代码 清单 18-15 所 示 。 


代码 清单 18-15 具体 策略 


public class Add implements Calculator { 
// 加 法 运算 
public int exec(int a, int b) { 
return a+b; 
} 


public class Sub implements Calculator { 
// 减 法 运算 
public int exec(int a, int b) { 
return a-b; 
} 








封装 角色 的 责任 是 保证 策略 时 可 以 相互 蔡 换 ， 如 代码 清单 18-15 所 


代码 清单 18-16 上 下 文 


public class Context { 
private Calculator cal = null; 
public Context(Calculator _cal)t{ 
this.cal = _cal; 


public int exec(int a,int b,String Symbol){ 
return this.cal.exec(a, b); 
} 


代码 都 非常 简单 ， 该 部 分 就 不 再 增加 注释 信息 了 。 上 下 文 类 负责 把 
策略 封装 起 来 ， 具 体 怎么 自由 地 切换 策略 则 是 由 高 层 模块 负责 声明 的 ， 
如 代码 清单 18-17 所 示 。 








代码 清单 18-17 场景 类 


public class Client { 
// 加 符号 
public final static String ADD_SYMBOL = "+"; 
// 减 符号 
public final static String SUB_SYMBOL = "-"; 
public static void main(String[|] args) { 
// 输 入 的 两 个 参数 是 数字 
int a = Integer.parseIint(args[0|]); 
String symbol = args[1]; // 符 号 
int b = Integer.parseIint(args[2]); 


System,out,.printlLn(" 输 入 的 参数 为 : "+Arrays.toString(art 


// 上 下 文 
Context context = null; 
// 判 断 初始 化 哪 一 个 策略 
if(symbol.equals(ADD_SYMBOL)){ 
context = new Context (new Add()); 
}else if(symbol.equals(SUB_SYMBOL))E 
context = new Context(new Sub()); 





System,out.printlLn(" 运 行 结果 为 : "+atsymbol+b+"="+conte 


结果 与 方案 一 相同 。 我 们 想 想 看 ， 在 该 策略 模式 的 一 个 具体 应 
用 中 ， 我 们 使 用 Context 准 备 了 一 组 算法 (加 法 和 减法 ) ， 并 封装 了 起 
来 ， 具 体 使 用 哪 一 个 策略 (加 法 还 是 减法 ) 则 由 上 层 模 块 声明 ， 


展 性 非常 好 。 


现在 只 剩 最 后 一 个 方案 了 ， 一 般 最 后 出 场 的 都 是 重量 级 的 人 物 ， 压 
场 嘛 ! 那 就 请 出 我 们 最 后 一 个 重量 级 角色 ， 首 乐 响起 ， 一 个 黑 影 
台中 央 ， 所 有 灯光 突然 聚焦 ， 主 角 绥 组 抬 起 头 ， 它 就 是 一 一 俩 


我 们 来 看 看 其 真实 实力 ， 如 代码 清单 18-18 所 示 。 





代码 清单 18-18 策略 枚 举 


public enum Calculator { 
// 加 法 运算 
ADD("+"){ 
public int exec(int a,int b)t 
return a+b ， 








} 
}, 
// 减 法 运算 
SUB("-")t{ 


public int exec(int a,int b)t{ 
return a - b; 





} 

}; 

String value = ""，; 

// 定 义 成 员 值 类 型 

private Calculator(String _value)t{ 
this.value = _value; 

} 

// 获 得 枚 举 成 员 的 值 


public String getValue(){ 
return this.value; 


/南明 一 个 抽象 函数 

public abstract int exec(int a,int b); 

先 想 一 想 它 的 名 字 ， 为 什么 叫做 策略 枚 举 ? 枚 举 没 有 问题 ， 它 就 是 
一 个 Enum 类 型 ， 那 为 什么 又 叫做 策略 呢 ? 找 找 看 能 不 能 找到 策略 的 影 
子 在 里 面 ? 是 的 ， 我 们 定义 了 一 个 抽象 的 方法 exec， 然 后 在 每 个 枚 举 成 
员 中 进行 了 实现 ， 如 果 不 实现 会 怎么 样 呢 ? 你 试 试看 看 ， 不 实现 该 方法 
就 不 能 编译 ， 现 在 是 不 是 清楚 了 ? 把 原 有 定义 在 抽象 策略 中 的 方法 移植 
到 枚 举 中 ， 每 个 枚 举 成 员 束 成 为 一 个 具体 策略 。 简 单 吧 ， 总 结 一 下 ， 策 
略 枚 举 定义 如 下 : 








e 它 是 一 个 枚 举 。 


e 它 古 一 个 浓 迪 了 的 集 略 模式 的 枚 举 。 


当然 ， 读 者 可 能 要 反 忠 了 ， 我 使 用 内 置 类 也 可 以 实现 相同 的 功能 ， 
写 一 个 Context 类 ， 然 后 把 抽象 策略 、 有 具体 策略 都 内 置 进去 ， 不 就 可 以 解 
决 问题 了 ， 是 的 ， 可 以 解决 ， 但 是 扩展 性 如 何 ? 可 读 性 如 何 ? 代码 是 让 
人 读 的 ， 然 后 才 是 让 机 器 执行 ， 别 把 顺序 搞 反 了 ! 


我 们 继续 完善 方案 四 ， 场 景 类 稍 有 改动 ， 如 代码 清单 18-19 所 示 。 


代码 清单 18-19 场景 类 


public class Client { 

public static void main(String[|] args) { 
// 输 入 的 两 个 参数 是 数字 
int a = Integer.parseIint(args[0|); 
String symbol = args[1]; // 符 号 
int b = Integer.parseInt(args[2]); 
System.out .println(" 输 入 的 参数 为 : "+Arrays.toString(ar( 
System,out.printlLn(" 运 行 结果 为 : "+atsymbol+b+"="+Calcu 
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运行 结果 与 方案 一 相同 。 看 这 个 场景 类 ， 代 码 量 非常 少 ， 而 且 还 有 
一 个 显著 的 优点 : 真实 地 面 癌 对象 ， 看 看 这 条 语句 : 





Calculator.ADD.exec(a, b) 


是 不 是 类 似 于 “ 拿 出 计算 器 (Calculator) ， 对 a 和 b 进 行 加 法 运算 
(ADD)，)， 并 立刻 执行 (exec)”， 这 与 我 们 日 常 接 触 逻辑 是 不 是 非常 相 





似 ， 这 也 正 是 我 们 染 构 师 要 担当 的 职责 ! 





注意 ”策略 枚 举 是 一 个 非常 优秀 和 方便 的 模式 ， 但 是 它 受 枚 举 类 
型 的 限制 ， 每 个 枚 举 项 都 是 public、final、static 的 ， 扩 展 性 受到 了 一 定 
的 约束 ， 因 此 在 系统 开发 中 ， 策 略 枚 举 一 般 担当 不 经 和 常 发 生变 化 的 角 
色 。 


18.5 最 佳 实践 





策略 模式 是 一 个 非常 简单 的 模式 。 它 在 项 目 中 使 用 得 非常 多 ， 但 它 
单独 使 用 的 地 方 就 比较 少 了 ， 因 为 它 有 致命 缺陷 : 所 有 的 全 略 都 需要 暴 
露出 去 ， 这 样 才 方便 客户 端 决 定 使 用 哪 一 个 策略 。 例 如 ， 在 例子 中 的 赵 
云 ， 实 际 上 不 知道 使 用 哪个 胰 略 ， 他 只 知道 拆 第 一 个 锅 宫 ， 而 不 知道 是 
BackDoor 这 个 妙计 。 是 的 ， 诸 馒 沈 已 经 在 规定 了 在 适当 的 场景 下 拆 开 指 
定 的 锅 吉 ， 我 们 的 策略 模式 只 是 实现 了 锅 宫 的 管理 ， 但 是 我 们 没有 严格 
地 定义 “适当 的 场景 ? 拆 开 <“ 适当 的 锅 圳 >”， 在 实际 项 目 中 ， 我 们 一 般 通 过 
工厂 方法 模式 来 实现 集 略 类 的 声明 ， 读 者 可 以 参考 泥 编 模式 。 

















第 19 章 ” 适 配 右 模式 


19.1 业务 发 展 一 一 上 帝 才 能 控制 


有 这 样 一 名 名言: “智者 千 虑 必 有 一 失 ， 愚 者 千 虑 必 有 一 得 ”H ， 
意思 是 说 不 管 多 聪明 的 人 ， 经 过 多 少 次 的 思考 ， 也 总 是 会 出 现 一 些微 小 
的 错误 ,，“ 智 者 ?都 是 如 此 ， 何 况 我 们 这 些 平 庸 之 替 呢 ! 我 们 在 进行 系统 
开发 时 ， 不 管 之 前 的 可 行 性 分 析 、 需 求 分 析 、 系 统 设 计 处 理 得 多 么 完 
美 ， 总 会 在 关键 时 候 、 关 键 场合 出 现 一 些 “ 意 外 ”。 对 于 这 些 “ 意 外 ”， 该 
来 的 还 是 要 来 ， 躲 是 躲 不 过 去 的 ， 那 我 们 怎么 来 弥补 这 些 “ 意 外 ” 呢 ? 这 
难 不 倒 我 们 的 设计 大 师 ， 他 们 创造 出 了 一 些 补救 模式 ， 今 天 我 们 就 来 讲 
一 个 补救 模式 ， 这 种 模式 可 以 让 你 从 因 业 务 扩展 而 系统 无 法 迅速 适应 的 
苦恼 中 解脱 而 出 。 

















2004 年 我 带 了 一 个 项 目 ， 做 一 个 人 力 资 源 管 理 项 目 ， 该 项 目 是 我 们 
总 公司 发 起 的 ， 公 司 一 共有 700 多 号 人 。 这 个 项 目 还 是 比较 简单 的 ， 分 
为 三 大 模块 : 人 员 信 息 管 理 、 薪 酬 管理 、 职 位 管理 。 当 时 开发 时 业务 人 
员 明 确 指明 : 人 员 信 息 管 理 的 对 象 是 所 有 员工 的 所 有 信息 ， 所 有 的 员工 
指 的 是 在 职 的 员工 ， 其 他 的 离职 的 、 退 休 的 暂 不 考虑 。 根 据 需 求 我 们 设 
计 了 如 图 19-1 所 示 的 类 图 。 








< 一 Interface>> 
IUserInfo 


tString getUserName()() 
+String getHomeAddress() 


+String getMobile Number() 
tStrng getOfficeTelINumber() 
+Strng getJobPosition() 
+String getHome TelNumber() 


| 
-i 


图 19-1 人 员 信 息 类 图 





非常 简单 ， 有 一 个 对 象 UserInfo 存 储 用户 的 所 有 信息 (实际 系统 上 
还 有 很 多 子 类 ， 不 多 说 了 ) ， 也 束 是 BO (Business Object， 业 务 对 
象 ) ， 这 个 对 象 设计 为 贫血 对 象 (Thin Business Object) ， 不 需要 存储 
状态 以 及 相关 的 关系 ， 本 人 是 反对 使 用 充血 对 象 〈Rich Business 
Object) ， 这 里 提 到 两 个 名 词 : 贫血 对 象 和 充血 对 象 ， 这 两 个 名 词 很 简 
单 ， 在 领域 模型 中 分 别 叫 做 贫血 领域 模型 和 充血 领域 模型 ， 有 什么 区 别 
呢 ? 一 个 对 象 如 果 不 存 储 实体 状态 以 及 对 象 之 间 的 关系 ， 该 对 象 就 叫做 
贫血 对 象 ， 对 应 的 领域 模型 就 是 贫血 领域 模型 ， 有 实体 状态 和 对 象 关 系 
的 模型 就 是 充血 领域 模型 。 看 不 懂 没 关系 ， 都 是 糊弄 人 的 东西 ， 属 于 专 





用 名 词 。 扯 远 了 ， 我 们 继续 说 我 们 的 人 力 资 源 管 理 项 目 ， 这 个 UserInfo 
对 象 ， 在 系统 中 很 多 地 方 使 用 ， 你 可 以 碍 看 自己 的 信息 ， 也 可 以 修改 ， 
当然 这 个 对 象 是 有 setter 方 法 的 ， 我 们 这 里 用 不 到 就 隐藏 卸 了 。 先 来 看 接 
口 ， 员 工 信 息 接口 如 代码 清单 19-1 所 示 。 


代码 清单 19-1 员工 信息 接口 


public interface IUserInfo { 
// 获 得 用 户 姓名 
public String getUserName( ) ; 
// 获 得 家 庭 地 址 
public String getHomeAddress( ) ; 
// 手 机 号 码 ， 这 个 太 重 要 ， 手 机 泛滥 呀 
public String getMobileNumber(); 
// 办 公 电 话 ， 一 般 是 座机 
public String getofficeTelNumber(); 
// 这 个 人 的 职位 是 什么 
public String getJobPosition( ) ; 
// 获 得 家 庭 电话， 这 有 点 不 好 ， 我 不 喜欢 打 家 许 电 话 讨 论 工作 
public String getHomeTelNumber(); 




















员工 信息 接口 有 了 ， 就 需要 设计 一 个 实现 类 来 容纳 数据 ， 如 代码 清 
单 19-2 所 示 。 


代码 清单 19-2 实现 类 


public class UserInfo implements IUSerInfo { 








hs 
* 获得 家 庭 地 址 ， 下 属 送礼 也 可 以 找到 地 方 
*/ 


public String getHomeAddress() { 
System.out.println(" 这 里 是 员工 的 家 庭 地 址 ...")， 
return null; 





4 
public String getHomeTelNumber() { 
System,out.println(" 员 工 的 家 庭 电 话 是 ,,.")， 
return null; 


























人 
* 员工 的 职位 ， 是 部 门 经 理 还 是 普通 职员 
*/ 


public String getJobPosition() { 
System.out.println(" 这 个 人 的 职位 是 B0SS. .."); 
return null; 

} 


/* 


* 手机 号 码 
*/ 


public String getMobileNumber() { 
System.out.printlLln(" 这 个 人 的 手机 号 码 是 0000. .."); 
return null; 
人 
* 办 公 室 电话 ， 烦 躁 的 时 候 最 好 "不 小 心 "把 电话 线 踢 掉 
WA 
public String getofficeTelNumber() { 
System.out.println(" 办 公 室 电 话 是 ...")，; 
return null; 


Tir 











} 
A 
* 姓名 ， 这 个 很 重要 
6 
public String getUserName() { 
System.out.printlin(" 姓 名 叫做 ..."); 
return null; 











这 个 项 目 是 2004 年 年 底 投 产 的 ， 运 行 到 2005 年 年 底 还 是 比较 平稳 
的 ， 中 间 修 修补 补 也 很 正常 ，2005 年 年 底 不 知道 是 哪 股 风 吹 的 ， 很 多 公 
司 开 始 使 用 借 聘 人 员 的 方式 引进 人 员 ， 我 们 公司 也 不 例外 ， 从 一 个 劳动 
资源 公司 借用 了 一 大 批 的 低 技术 、 低 工资 的 人 员 ， 分 配 到 各 个 子 公 司 ， 
总 共有 将 近 200 人 ， 然 后 人 力 资 源 部 就 找 我 们 部 门 老大 谈判 ， 说 要 增加 


一 个 功能 : 借用 人 员 管 理 ， 老 大 一 看 有 钱 赚 呀 ， 一 拍 大 腿 ， 做 ! 


老大 命令 一 下 来 ， 我 立马 带 人 过 去 调研 ， 需 求 就 一 句 话 ， 但 是 真 深 
入 地 调研 还 真 不 是 那么 简单 。 借 聘 人 员 虽 然 在 我 们 公司 干 活 ， 和 我 们 一 
个 样 ， 干 活 时 没有 任何 的 差别 ， 但 是 他 们 的 人 员 人 信息、 工资 情况 、 福 利 
情况 等 都 是 由 劳动 服务 公司 管理 的 ， 并 且 有 一 套 自己 的 人 员 管 理 系统 ， 
人 力 资 源 部 门 就 要 求 我 们 系统 同步 劳动 服务 公司 的 信息 ， 当 然 是 只 要 在 
我 们 公司 工作 的 人 员 信 息 ， 其 他 人 员 信 息 是 不 需要 的 ， 而 且 还 要 求 信息 
同步 ， 也 就 是 : 劳动 服务 公司 的 人 员 信 息 一 变更 ， 我 们 系统 就 应 该 立刻 
体现 出 来 ， 为 什么 要 即时 而 不 批量 呢 ? 是 因为 我 们 公司 与 劳动 服务 公司 
之 间 是 按照 人 头 收费 的 ， 击 管 是 什么 人 ， 只 要 我 们 公司 借用 ， 就 这 个 价 
格 ， 我 要 一 个 研究 生 ， 你 派 了 一 个 高 中 生 给 我 ， 那 算 什么 事 ? 因此， 了 
解 了 业务 需求 用 后 ， 项 目 组 决定 采用 RMI (Remote Method Invocation， 
远程 对 象 调用 ) 的 方式 进行 联机 交互 ， 但 是 深入 分 析 后 ， 一 个 重大 问题 
立刻 显现 出 来 : 劳动 服务 公司 的 人 员 对 象 和 我 们 系统 的 对 象 不 相同 ， 他 
们 的 对 象 如 下 所 示 。 

















<<Interface>> 
IOQuterUser 


+Map getUserBaselInfo() 


+Map getUserOtficeInfo() 
+Map getUserHomelInfo() 





he 
ee 


图 19-2 劳动 服务 公司 的 人 员 信 息 类 图 





劳动 服务 公司 是 把 人 员 信 息 分 为 了 三 部 分 : 基本 信息 、 办 公信 息 和 
个 人 家 庭 信 息 ， 并 且 都 放 到 了 HashMap 中 ， 比 如 人 员 的 姓名 放 到 
BaseInfo 信 息 中 ， 家 庭 地 址 放 到 HomeInfo 中 ， 这 也 是 一 个 可 以 接受 的 模 
式 ， 我 们 来 看 看 他 们 的 代码 ， 接 口 如 代码 清单 19-3 所 示 。 


代码 清单 19-3 劳动 服务 公司 的 人 员 信 息 接 口 


public interface IOuterUser { 
// 基 本 信息 ， 比 如 名 称 、 性 别 、 手 机 号 码 等 
public Map getUserBaseInfo( ) ， 
// 工 作 区 域 信息 





public Map getUserofficeInfo( ) ; 
// 用 户 的 家 庭 信息 
public Map getUserHomeInfo( ) ; 





丈 动 服务 公司 的 人 员 信息 是 这 样 存 放 的 ， 如 代码 清单 19-4 所 示 。 


代码 清单 19-4 劳动 服务 公司 的 人 员 实 现 
public class OuterUser implements IOuterUser { 
* 用 户 的 基本 信息 


public Map getUserBaseInfo() { 
HashMap baseInfoMap = new HashMap(); 
baseInfoMap.put("userName"，“" 这 个 员工 叫 混 世 磨 王 ,.."); 
baseInfoMap.put("mobileNumber"， "这 个 员工 电话 是 ..."); 
return baseInfoMap; 























4 

yy 

* 员工 的 家 庭 信 息 
*/ 


public Map getUserHomeInfo() { 
HashMap homeInfo = new HashMap(); 
homeInfo.put("homeTelNumbner", a ws 
homeInfo.put("homeAddress",， "员工 的 家 庭 地 址 是 .. 中 
return homeInfo; 
} 
/* 
* 员工 的 工作 信息 ， 比 如 ， 职 位 等 
*/ 
public Map getUserOofficeInfo() { 
HashMap officeInfo = new HashMap(); 
officeInfo.put("jobPosition", "这 个 人 的 职位 是 BOSS ., ， 
officeInfo.put("officeTelNumber", "员工 的 办 公 电 话 是 ， 
return officeInfo; 








看 到 这 里 ， 咀 不 好 说 他 们 系统 设计 得 不 好 ， 问 题 是 咀 的 系统 要 和 他 
们 的 系统 进行 交互 ， 怎 么 办 ? 我 们 不 可 能 为 了 这 一 小 小 的 功能 而 对 我 们 





已 经 运行 良好 系统 进行 大 手术 ， 那 怎么 办 ? 我 们 可 以 转化 ， 先 拿 到 对 方 
的 数据 对 象 ， 然 后 转化 为 我 们 自己 的 数据 对 象 ， 中 间 加 一 层 转 换 处 理 ， 
按照 这 个 思路 ， 我 们 设计 了 如 图 19-3 所 示 的 类 图 。 


<<Interface>> 
IUserInfo 
| 
+Strmg getUserName()() 
+Strng getHomeAddress() 
+String getMobile Number() 


+String getOfficeTelNumber() 


<<Interface>> 
IOQuterUser 








+Map getUserBaseInfo() 


+Map getUserOfficeInfo() 
+Map getUserHomelInfo() 





+Strng getJobP osition() 
+String getHome TelNumber() 


OuterUserlnfo ~ OuterUser 
QQ QT Ss 


图 19-3 增加 了 中 转 处 理 的 人 员 信 息 类 图 


大 家 可 能 会 问 ， 这 两 个 对 象 都 不 在 一 个 系统 中 ， 你 如 何 使 用 呢 ? 简 
单 ! RMI 己 经 帮 我 们 做 了 这 件 事情 ， 只 要 有 接口 ， 束 可 以 把 远程 的 对 象 
当成 本 地 的 对 象 使 用 ， 这 个 大 家 有 了 时间 可 以 去 看 一 下 MI 文档 ， 不 多 说 
了 。OuterUserInfo 可 以 看 做 是 “两 面 派 " 实现 了 IUserInfo 接 口 ， 还 继承 
了 OuterUser， 通 过 这 样 的 设计 ， 把 OuterUser 伪 装 成 我 们 系统 中 一 个 
IUserInfo 对 象 ， 这 样 ， 我 们 的 系统 基本 不 用 修改 ， 所 有 的 人 员 人 查询 、 调 
用 跟 本 地 一 样 。 











注意 ”我们 之 所 以 能 够 增加 一 个 OuterUserInfo 中 转 类 ， 是 因为 我 们 
在 系统 设计 时 严格 遵守 了 依赖 倒置 原则 和 里 氏 符 换 原则 ， 人 否则 即使 增加 
了 中 转 类 也 无 法 解决 问题 。 





说 得 口 干 舌 燥 ， 下 边 我 们 来 看 具体 的 代码 实现 ， 中 转角 色 
OuterUserInfo 如 代码 清单 19-5 所 示 。 


代码 清单 19-5 中 转角 色 


public class OuterUserInfo extends OuterUser implements IUserInfo 
private Map baseInfo = super.getUserBaseInfo(); // 员 工 的 基本 人 
private Map homeInfo = super.getUserHomeInfo(); // 员 工 的 家 庭 信 
private Map officeInfo = super.getUser0officeInfo(); // 工 作 信 点 
yh 
* 家 庭 地 址 
*/ 
public String getHomeAddress() { 
String homeAddress = (String)this.homeInfo.get("home 
System.out.println(homeAddress); 
return homeAddress; 
} 
~/ 
* 家 庭 电话 号 码 
*/ 
public String getHomeTelNumber() { 
String homeTelNumber = (String)this.homeInfo.get("ho 
System.out.println(homeTelNumber ); 
return homeTelNumber; 
} 
/* 
* 职 位 信息 
*/ 


public String getJobPosition() { 
String jobPosition = (String)this.officeInfo.get("jo 
System.out.println(jobPosition); 
return jobPosition; 


/* 


* 手机 号 码 
*/ 


public String getMobileNumber() { 
String mobileNumber = (String)this.baseInfo.get("mob 
System.out.println(mobileNumber ); 
return mobileNumber; 
} 
A* 
* 办 公 电 话 
*/ 


public String getofficeTelNumber() { 
String officeTelNumber = (String)this.officeIinfo.get 
System.out.println(officeTelNumber ) ; 
return officeTelNumber,; 


} 

7* 
* 员工 的 名 称 
*/ 


public String getUserName() { 
String userName = (String)this.baseInfo.get("userNam 
System.out.println(userName); 
return userName; 


大 家 看 到 没 ? 中 转 的 角色 有 很 多 的 强制 类 型 转换 ， 就 是 (String) 这 个 
东西 ， 如 果 使 用 泛 型 的 话 ， 就 可 以 完全 避免 这 个 转化 (当然 了 ， 泛 型 当 
时 还 没有 诞生 ) 。 我 们 要 看 看 这 个 中 转 是 否 真 的 起 到 了 中 转 的 作用 ， 我 
们 想象 这 样 一 个 场景 : 公司 大 老板 想 看 看 我 们 自己 公司 年 轻 女孩 子 的 电 
话 号 码 ， 那 该 场景 类 就 如 代码 清单 19-6 所 示 。 





代码 清单 19-6 场景 类 


public class Client { 
public static void main(String[] args) { 
// 没 有 与 外 系统 连接 的 时 候 ， 是 这 样 写 的 
IUSerInfo youngGirl = new UserInfo(); 
// 从 数据 库 中 查 到 101 个 
for(int i=0;i<101;i++){ 











youngGirl.getMobileNumber(); 


这 老板 比较 色 呀 。 从 数据 库 中 生成 了 101 个 UserInfo 对 象 ， 直 接 打 印 
出 来 束 成 了 。 老 板 回 头 一 想 ， 不 对 呀 ， 倪 子 不 吃 富 边 草 ， 还 是 调 取 借用 
人 员 看 看 ， 于 是 要 查询 出 借用 人 员 中 美女 的 电话 号 码 ， 如 代码 清单 19-7 
所 示 。 








代码 清单 19-7 但 看 劳动 服务 公司 人 员 信 息 场 景 


public class Client { 
public static void main(String[] args) { 
// 老 板 一 想 不 对 呀 ， 人 银子 不 吃 久 边 草 ， 还 是 找 借用 人 员 好 点 
// 我 们 只 修改 了 这 人 句 话 
IUSerInfo youngGirl = new OuterUserInfo( ) ; 
// 从 数据 库 中 碍 到 101 个 
for(int i=0;i<101;i++){ 
youngGirl.getMobileNumber(); 
} 


大 家 看 ， 使 用 了 运 配器 模式 只 修改 了 一 句 话 ， 其 他 的 业务 逻辑 都 不 
用 修改 就 解决 了 系统 对 接 的 问题 ， 而 且 在 我 们 实际 系统 中 只 是 增加 了 一 
个 业务 类 的 继承 ， 束 实现 了 可 以 但 本 公司 的 员工 信息 ， 也 可 以 但 人 力 资 
源 公司 的 员工 信息 ， 尺 量 少 的 修改 ， 通 过 扩展 的 方式 解决 了 该 问题 。 这 
就 是 适 配 模式 。 





[出 目 《 史 记 : 卷 九 十 二 》。 


19.2 适 配 絮 模式 的 定义 


适配器 模式 〈Adapter Pattern〉 的 定义 如 下 : 


Convert the interface of a class into another interface clients 
expect.Adapter lets classes work together that couldn't otherwise because of 
incompatible interfaces.〈 将 一 个 类 的 接口 变换 成 客户 端 所 期 待 的 另 一 种 
接口 ， 从 而 使 原本 因 接 口 不 匹配 而 无 法 在 一 起 工作 的 两 个 类 能 够 在 一 起 
Ee 





适 配 占 模式 又 叫做 变压器 模式 ， 也 叫做 包装 模式 (Wrapper) ， 但 
是 包 疙 模式 可 不 止 一 个 ， 还 包括 了 第 17 章 讲解 的 装饰 模式 。 适 配 右 模式 
的 通用 类 图 ， 如 图 19-4 所 示 。 













+SpecificRequest() 


图 19-4 适配器 模式 通用 类 图 


适配器 模式 在 生活 中 还 是 很 常见 的 ， 比 如 你 笔记 本 上 的 电源 适 配 
器 ， 可 以 使 用 在 110 一 220V 之 间 变 化 的 电源 ， 而 笔记 本 还 能 正常 工作 ， 
这 也 是 适配器 一 个 良好 模式 的 体现 ， 简 单 地 说 ， 适 配器 模式 就 是 把 一 个 
接口 或 类 转换 成 其 他 的 接口 或 类 ， 从 另 一 方面 来 说 ， 适 配器 模式 也 就 是 
一 个 包装 模式 ， 为 什么 呢 ? 它 把 Adaptee 包 装 成 一 个 Target 接 口 的 类 ， 加 
了 一 层 衣 服 ， 包 装 成 另外 一 个 靓 妞 了 。 大 家 知道 ， 设 计 模式 原 是 为 建筑 
设计 而 服务 的 ， 软 件 设计 模式 只 是 借用 了 人 家 的 原理 而 已 ， 那 我 们 来 看 
看 最 原始 的 适配器 是 如 何 设计 的 ， 如 图 19-5 所 示 。 








A、B 两 个 图 框 代表 已 经 塑 模 成 型 的 物体 A 和 物体 B， 那 现在 要 求 把 
A 和 B 安 装 在 一 起 使 用 ， 如 何 安 装 ? 两 者 的 接口 不 一 致 ， 是 不 可 能 安 闭 
在 一 起 使 用 的 ， 那 怎么 办 ? 引入 一 个 物体 C， 如 图 19-6 所 示 。 


四 2 


图 19-5 两 个 已 经 成 型 的 物体 
19-6 引入 物体 C 





引入 物体 C 后 ，C 适 应 了 物体 A 的 接口 ， 同 时 也 适应 了 物体 B 的 接 
口 ， 然 后 三 者 就 可 以 组 合成 一 个 完整 的 物体 ， 如 图 19-7 所 示 。 


图 19-7 完美 组 合 


其 中 的 物体 C 就 是 我 们 说 的 适配器 ， 它 在 中 间 起 到 了 角色 转换 的 作 
用 ， 把 原 有 的 长 条 形 接口 转换 了 三 角形 接口 。 在 我 们 软件 业 的 设计 模式 
中 ， 适 配器 模式 也 是 相似 的 功能 ， 那 我 们 先 来 看 看 适 配 占 模式 的 三 个 角 





e Target 目 标 角 色 


该 角色 定义 把 其 他 类 转换 为 何 种 接口 ， 也 就 是 我 们 的 期 望 接 口 ， 例 
子 中 的 IUserImfo 接 口 就 是 目标 角色 。 


e Adaptee 源 角色 

你 想 把 谁 转换 成 目标 角色 ， 这 个 “ 谁 ” 就 是 源 角 色 ， 它 是 已 经 存在 
的 、 运 行 良 好 的 类 或 对 象 ， 经 过 适配器 角色 的 包装 ， 它 会 成 为 一 个 窑 
新 、 靓 丽 的 角色 。 

e Adapter 适 配器 角色 

适配器 模式 的 核心 角色 ， 其 他 两 个 角色 都 是 已 经 存在 的 角色 ， 而 适 
配器 角色 是 需要 新 建立 的 ， 它 的 职责 非常 简单 : 把 源 角 色 转 换 为 目标 角 
色 ， 怎 么 转换 ? 通过 继承 或 是 类 关联 的 方式 。 

各 个 角色 的 职责 都 已 经 非常 清楚 ， 我 们 再 来 看 看 其 通用 源码 ， 目 标 
接口 如 代码 清单 19-8 所 示 。 

代码 清单 19-8 目标 角色 


public interface Target { 
目标 角色 有 自己 的 方法 
public void request(); 




















目标 角色 是 一 个 已 经 在 正式 运行 的 角色 ， 你 不 可 能 去 修改 角色 中 的 


方法 ， 你 能 做 的 就 是 如 何 去 实 现 接口 中 的 方法 ， 而 且 通 常情 况 下 ， 目 标 
角色 是 一 个 接口 或 者 是 抽象 类 ， 一 般 不 会 是 实现 类 。 一 个 正在 服役 的 目 
标 角 色 ， 如 代码 清单 19-9 所 示 。 


代码 清单 19-9 目标 角色 的 实现 类 


public class ConcreteTarget implements Target { 
public void request() { 
System.out.println("if you need any help,pls call me 


源 角色 也 是 已 经 在 服役 状态 〈 当 然 ， 非 要 新 建立 一 个 源 角 色 ， 然 后 
套用 适配器 模式 ， 那 也 没有 任何 问题 ) ， 它 是 一 个 正常 的 类 ， 其 源 代码 
如 代码 清单 19-10 所 示 。 


代码 清单 19-10 源 角 色 


public class Adaptee { 
// 原 有 的 业务 逻辑 
public void doSomething(){ 
System.out.println("I'm kind of busy,1leave me alone, 
} 




















我 们 的 核心 角色 要 出 场 了 ， 适 配器 角色 如 代码 清单 19-11 所 示 。 


代码 清单 19-11 适配器 角色 


public class Adapter extends Adaptee implements Target { 
public void request() { 
super .doSomething(); 
} 


所 有 的 角色 都 已 经 在 场 了 ， 那 我 们 就 开始 看 看 这 场 演出 ， 场 景 类 如 
代码 清单 19-12 所 示 。 


代码 清单 19-12 场景 类 


public class Client { 

public static void main(String[] args) { 
// 原 有 的 业务 逻辑 
Target target = new ConcreteTarget(); 
target.request(); 
// 现 在 增加 了 适配器 角色 后 的 业务 逻辑 
Target target2 = new Adapter(); 
target2.request( ) ; 












































适配器 模式 的 原理 就 讲 这 么 多 吧 ， 但 是 别 得 意 得 太 早 了 ， 如 果 你 认 
为 适配器 模式 就 这 么 简单 ， 那 我 告诉 你 ， 你 错 了 1! 复杂 的 还 在 后 面 。 


19.3 适配器 模式 的 应 用 


19.3.1 适配器 模式 的 优点 





e 适 配 右 模式 可 以 让 两 个 没有 任何 关系 的 类 在 一 起 运行 ， 只 要 适 配 
锅 这 个 角色 能 够 搞定 他 们 就 成 。 


e 增加 了 类 的 透明 性 


想 想 看 ， 我 们 访问 的 Target 目 标 角 色 ， 但 是 具体 的 实现 都 委托 给 了 
源 角 色 ， 而 这 些 对 高 层次 模块 是 透明 的 ， 也 是 它 不 需要 关心 的 。 





e 所 高 了 类 的 复 用 度 


当然 了 ， 源 角色 在 原 有 的 系统 中 还 是 可 以 正常 使 用 ， 而 在 目标 角色 
中 也 可 以 充当 新 的 演员 。 
e 灵活 性 非 第 好 


东 一 天 ， 突 然 不 想 要 适配器 ， 没 问题 ， 删 除 挤 这 个 适配器 就 可 以 
了 ， 其 他 的 代码 都 不 用 修改 ， 基 本 上 束 类 似 一 个 灵活 的 构件 ， 想 用 就 
用 ， 不 想 就 邮 载 。 


19.3.2 适配器 模式 的 使 用 场景 





适配器 应 用 的 场景 只 要 记 住 一 点 束 足 够 了 : 你 有 动机 修改 一 个 已 经 
投产 中 的 接口 时 ， 适 配器 模式 可 能 是 最 适合 你 的 模式 。 比 如 系统 扩展 
了 ， 需 要 使 用 一 个 已 有 或 新 建立 的 类 ， 但 这 个 类 又 不 符合 系统 的 接口 ， 
怎么 办 ? 使 用 适配器 模式 ， 这 也 是 我 们 例子 中 提 到 的 。 





19.3.3 适配器 模式 的 注意 事项 





适配器 模式 最 好 在 详细 设计 阶段 不 要 考虑 它 ， 它 不 是 为 了 解决 还 处 
在 开发 阶段 的 问题 ， 而 是 解决 正在 服役 的 项 目 问题 ， 没 有 一 个 系统 分 析 
师 会 在 做 详细 设计 的 时 候 考 虑 使 用 适配器 模式 ， 这 个 模式 使 用 的 主要 场 
景 是 扩展 应 用 中 ， 束 像 我们 上 面 的 那个 例子 一 样 ， 系 统 扩展 了 ， 不 符合 
原 有 设计 的 时 候 才 考虑 通过 适配器 模式 减少 代码 修改 种 来 的 风险 。 





再 次 提醒 一 点 ， 项 目 一 定 要 如 守 依 赖 倒置 原则 和 里 氏 蔡 换 原则 ， 
则 即使 在 适合 使 用 适配器 的 场合 下 ， 也 会 带 来 非常 大 的 改造 。 


19.4 适配器 模式 的 扩展 


我 们 刚刚 讲 的 人 力 资源 管理 的 例子 中 ， 其 实 是 一 个 比较 幸运 的 例 
子 ， 为 什么 呢 ? 如 果 劳 动 服务 公司 提供 的 人 员 接 口 不 止 一 个 ， 也 就 是 
说 ， 用 户 基本 信息 是 一 个 接口 ， 工 作 信息 是 一 个 接口 ， 家 庭 信息 是 一 个 
接口 ， 总 共有 三 个 接口 三 个 实现 类 ， 想 想 看 如 何 处 理 呢 ? 不 能 再 使 用 我 
们 上 面 的 方法 了 ， 为 什么 呢 ? Java 是 不 支持 多 继承 的 ， 你 难道 想 让 
OuterUserInfo 继 承 三 个 实现 类 ?此 路 不 通 ， 再 想 一 个 办 法 ， 对 哦 ， 可 以 
使 用 类 关联 的 办 法 嘛 ! 声明 一 个 OuterUserInfo 实 现 类 ， 实 现 IUserInfo 接 
口 ， 通 过 再 关联 其 他 三 个 实现 类 不 就 可 以 解决 这 个 问题 了 吗 ? 是 的 ， 是 
的 ， 好 方法 ， 我 们 先 画 出 类 图 ， 如 图 19-8 所 示 。 

















OnuterUserInfo 通 过 关联 的 方式 与 外 界 的 三 个 实现 类 通讯 ， 当 然 也 可 
以 理解 为 是 聚合 关系 。IUserInfo 和 UserInfo 代 码 如 代码 清单 19-1 和 代码 
清单 19-2 所 示 ， 不 再 歼 述 。 我 们 来 看 看 拆 分 后 的 三 个 接口 和 实现 类 ， 用 
户 基本 信息 接口 如 代码 清单 19-13 所 示 。 











<<Interface>> 
IJOuterUserBaseInfo 


<<interface>> 
IUserlInfo 

El 

re eee 

+Strng getHomeAddress() A 

+Strng getMobile Number() 

+String getOfficeTeINumber() 

+String getJobP osition() OuterUserBaselnfo 

+Strng gctHome TeclINumber() 








<<interface>> 
IOuterUserHomeJnfio 


| 
+Map getUserHomeInfo() 


OuterUserHomeJnfo 








<<Interface>> 
IOuterOffice Info 


+Map getUserOfficeInfo() 


OuterUserOfficeInfo 


图 19-8 拆 分 接口 后 的 类 图 











代码 清单 19-13 用 户 基 本 信息 接口 


public interface IOuterUserBaseInfo { 
// 基 本 信息 ， 比 如 名 称 、 性 别 、 手 机 号 码 等 
public Map getUserBaseInfo( ) ; 





用 户 家 庭 信 息 接口 如 代码 清单 19-14 所 示 。 





代码 清单 19-14 用 户 家 庭 信息 接口 


public interface IOuterUserHomeInfo { 
// 用 户 的 家 庭 信息 
public Map getUserHomeInfo( ) ; 








用 户 工 作 信息 接口 如 代码 清单 19-15 所 示 。 





代码 清单 19-15 用 户 工作 信息 接口 


public interface IOuterUserofficeInfo { 
// 工 作 区 域 信息 
public Map getUserofficeInfo( ) ; 


读 到 这 里 ， 读 者 应 该 想到 这 样 一 个 问题 : 系统 这 样 设计 是 售 合 理 
呢 ? 合理 ， 绝 对 合理 ! 想 想 单 一 职责 原则 是 怎么 说 的 ， 类 和 接口 要 保持 
职 贡 单一 ， 在 实际 的 应 用 中 类 可 以 有 多 重 职责 ， 但 是 接口 一 定 要 职责 单 

因此 ， 我 们 上 面 拆 分 接口 的 假想 也 是 非常 合乎 逻辑 的 。 我 们 来 看 三 
个 相关 的 实现 类 ， 用 户 基 本 信息 如 代码 清单 19-16 所 示 。 





代码 清单 19-16 用 户 基本 信息 
public class OuterUserBaseInfo implements IOuterUserBaseInfo { 


* 用 户 的 基本 信息 











public Map getUserBaseInfo() { 
HashMap baseInfoMap = new HashMap(); 
baseInfoMap .put("userName"，“" 这 个 员工 叫 温 世 魔王 ,.."); 
baseInfoMap.put("mobileNumber"， "这 个 员工 电话 是 ..."); 





return baseInfoMap ; 


用 户 家 庭 信 息 如 代码 清单 19-17 所 示 。 


代码 清单 19-17 用 户 家 庭 信 息 


public class OuterUserHomeInfo implements IOuterUserHomeInfo { 
A* 
* 员工 的 家 庭 信息 
yA 
public Map getUserHomeInfo() { 
HashMap homeInfo = new HashMap(); 
homeInfo.put("homeTelNumbner", 和 3 
homeInfo.put("homeAddress",， "员工 的 家 庭 地 址 是 .， "); 
return homeInfo ， 











用 户 工作 信息 如 代码 清单 19-18 所 示 。 


代码 清单 19-18 用 户 工作 信息 


public class OuterUserofficeInfo implements IOuterUserofficeInfo 


， 员工 的 工作 信息 ， 比 如 ， 职 位 等 
yA 
public Map getUserOofficeInfo() { 
HashMap officeInfo = new HashMap(); 
officeInfo.put("jobPosition", "这 个 人 的 职位 是 BOSS ., ， 0 
officeInfo.put("officeTelNumber", "员工 的 办 公 电 话 是 ， 
return officeInfo; 





这 里 又 到 我 们 的 核心 了 一 一 适配器 。 好 ， 我 们 来 看 适配器 代码 ， 如 
代码 清单 19-19 所 示 。 


代码 清单 19-19 适配器 


public class OuterUserInfo implements IUserInfo { 








// 源 目标 对 象 
private IOuterUserBaseInfo baseInfo = null,; // 员 工 的 基本 信 
private IOuterUserHomeInfo homeInfo = null,; // 员 工 的 家 庭 信 


private IOuterUser0fficeInfo officeInfo = null; // 工 作 信 息 
// 数 据 处 理 
private Map baseMap null; 
private Map homeMap null; 
private Map officeMap = null; 























// 构 造 函 数 传递 对 象 
public OuterUserIinfo(IOuterUserBaseInfo _baseInfo,IOuterUser 
this.baseInfo = _baseInfo， 
this.homeInfo = _homeInfo， 
this.officeInfo = _officeInfo; 
// 数 据 处 理 




















this.baseMap this.baseInfo.getUserBaseInfo( ) ; 
this.homeMap this.homeInfo.getUserHomeInfo( ) ; 
this.officeMap = this.officeInfo.getUserofficeInfo( ) 


} 

// 家 庭 地 址 

public String getHomeAddress() { 
String homeAddress = (String)this.homeMap.get("homeA 
System.out.println(homeAddress ) ; 
return homeAddress 


} 

// 家 庭 电 话 号 码 

public String getHomeTelNumber() { 
String homeTelNumber = (String)this.homeMap.get("hom 
System.out.println(homeTelNumber ); 
return homeTelNumber; 


} 
// 职 位 信息 
public String getJobPosition() { 

String jobPosition = (String)this.officeMap.get("job 

System.out.println(jobPosition); 

return jobPosition; 


} 

// 手 机 号 码 

public String getMobileNumber() { 
String mobileNumber = (String)this.baseMap.get("mobi 
System.out.println(mobileNumber ); 
return mobileNumber; 


// 办 公 电 话 





public String getofficeTelNumber() { 
String officeTelNumber= (String)this,officeMap ,get(" 
System.out.println(officeTelNumber ) ; 
return officeTeJNumber ， 


} 

// 员工 的 名 称 

public String getUserName() { 
String userName = (String)this.baseMap.get("userName 
System.out.println(userName); 
return userName; 








大 家 只 要 注意 一 下 黑色 字体 的 构造 函数 就 可 以 了 ， 它 接收 三 个 对 
象 ， 其 他 部 分 变化 不 大 ， 只 是 变量 名 称 进行 了 修改 ， 我 们 再 来 看 场景 
类 ， 如 代码 清单 19-20 所 示 。 


代码 清单 19-20 场景 类 


public class Client { 
public static void We args) 1{ 

// 外 系统 的 人 员 信 息 

IOuterUserBaseInfo baseInfo = new OuterUserBaseInfo( 
IOuterUserHomeInfo homeInfo = new OuterUserHomeInfo( 
IOuterUserofficeInfo officeInfo = new OuterUseroffic 
// 传 递 三 个 对 象 

IUserInfo youngGirl = new OuterUserInfo(baseInfo,ho 
// 从 数据 库 中 碍 到 101 个 
for(int i=0;i<101;i++){ 

youngGirl.getMobileNumber(); 

} 





运行 的 结果 还 是 相同 的 。 大 家 想 想 看 ，OuterUserInfo 变 成 了 委托 服 
务 ， 把 IUserInfo 接 口 需 要 的 所 有 的 操作 都 委托 给 其 他 三 个 接口 下 的 实现 
类 ， 它 的 委托 是 通过 对 象 层次 的 关联 关系 进行 委托 的 ， 而 不 是 继承 关 











系 。 好 了 ， 讲 了 这 么 多 ， 我 们 需要 给 这 种 适配器 起 个 名 字 ， 就 是 对 象 适 
配器 ， 我 们 之 前 讲 的 通过 继承 进行 的 适 配 ， 叫 做 类 适配器 。 对 象 适 配器 
的 通用 类 图 ， 如 图 19-9 所 示 。 


十 Request( 


有 


Adapteel 
EE | 
+SpecificRequest() 





图 19-9 对 象 适配器 类 图 


适配器 的 通用 代码 也 比较 简单 ， 把 原 有 的 继承 关系 变更 为 天 联 天 系 
就 可 以 了 ， 不 再 歼 述 。 对 象 适 配器 和 类 适配器 的 区 别 是 : 类 适配器 是 类 
间 继 承 ， 对 象 适配器 是 对 象 的 合成 关系 ， 也 可 以 说 是 类 的 天 联 关 系 ， 这 
征 两 者 的 根本 区 别 。 二 者 在 实际 项 目 中 都 会 经 常用 到 ， 由 于 对 象 适 配器 
征 通过 类 间 的 关联 关系 进行 硝 合 的 ， 因 此 在 设计 时 就 可 以 做 到 比较 灵 
活 ， 比 如 修补 源 角色 的 隐形 缺陷 ， 关联 其 他 对 象 等 ， 而 类 适配器 就 只 能 
通过 禾 写 源 角 色 的 方法 进行 扩展 ， 在 实际 项 目 中 ， 对 象 适配器 使 用 到 场 
景 相对 较 多 。 

















19.5 最 佳 实践 


适配器 模式 是 一 个 补偿 模式 ， 或 者 说 是 一 个 “补救 "模式 ， 通 第 用 来 
解决 接口 不 相 容 的 问题 ， 在 百分之百 的 完美 设计 中 是 不 可 能 使 用 到 的 ， 
什么 是 百分之百 的 完美 设计 ?“ 千 虑 ”而 没有 “一 失 ” 的 设计 ， 但 是 ， 再 完 
美的 设计 也 会 遇 到 “需求 "变更 这 个 无 法 逃避 的 问题 ， 束 以 我 们 上 面 的 人 
力 资 源 管理 系统 为 例 来 说 ， 不 管 系统 设计 得 多 么 完美 ， 痢 无 法 逃避 新 业 
务 的 发 生 ， 技 术 只 是 一 个 工具 而 已 ， 是 因为 它 推动 了 其 他 行业 的 进步 和 
发 展 而 具有 了 价值 ， 通 俗 地 说 ， 技 术 是 为 业务 服务 的 ， 因 此 业务 在 日 新 
月 腊 变 化 的 同时 ， 也 对 技术 提出 了 同样 的 要 求 ， 在 这 种 要 求 下 ， 束 需要 
我 们 有 一 种 或 一 些 这 样 的 补救 模式 诞生 ， 使 用 这 些 补救 模式 可 以 保证 我 
们 的 系统 在 生命 周期 内 能 够 稳定 、 可 徘 、 健 壮 的 运行 ， 而 适配器 模式 就 
古 这 样 的 一 个 “救世 主 *”， 它 在 需求 巨变 、 业 务 飞 速 而 导致 你 极度 郁 闽 、 
烦躁 、 骨 尝 的 时 候 模 空 出 世 ， 它 通过 把 非 本 系统 接口 的 对 象 包装 成 本 系 
统 可 以 接受 的 对 象 ， 从 而 简化 了 系统 大 规模 变更 风险 的 存在 。 


























第 20 章 ”迭代 和 硕 模 式 


20.1 整理 项 目 信 息 二 








周 五 下 午 ， 我 正在 看 技术 网 站 ， 第 六 感官 发 党 有 人 在 身后 ， 扭 头 一 
看 ， 老 大 站 在 背后 ， 我 赶忙 站 起 来 。 


“ 王 经 理 ， 你 找 我 ? ” 


“< 哦 ， 在 看 技术 呀 。 有 个 事情 找 你 谈 一 下 ， 你 到 我 办 公 室 来 一 下 。” 


到 老大 办 公 室 还 没 坐 稳 ， 老 大 就 开始 及 话 了。 


“是 这 样 ， 刚 刚 我 在 看 季报 ， 我 们 每 个 项 目的 文 出 费用 都 很 高 ， 项 
目 情 况 复 本， 人 员 情 况 也 不 简单 ， 我 看 着 也 有 点 糊涂 ， 你 看 ， 这 是 我 们 
现在 还 在 开发 或 者 维护 的 103 个 项 目 ， 项 目 信 息 很 乱 ， 很 多 是 两 年 前 的 
信息 ， 你 能 不 能 先 把 这 些 项 目 最 新 情况 重新 打印 一 份 给 我 ， 咀 们 好 碍 奉 
到 撒 有 什么 问题 。” 老 大 说 。 


“这 个 好 办 ， 我 马上 去 办 ! 我 爽快 地 答复 道 。 


很 快 我 设计 了 一 个 类 图 ， 准 备 实施 ， 如 图 20-1 所 示 。 


<<interface>> 
IProject 
+Strng getProjectInfo() 


人 


图 20-1 项 目 信 息 类 














简单 得 不 能 再 简单 的 类 图 ， 和 是 个 程序 员 都 能 实现 。 我 们 来 看 看 这 个 
简单 的 东西 ， 先 看 接口 ， 如 代码 清单 20-1 所 示 。 


代码 清单 20-1 项 目 信 息 接口 


public interface IProject { 
// 从 老板 这 里 看 到 的 就 是 项 目 信 息 
public String getProjectInfo( ) ; 





定义 了 一 个 接口 ， 面 向 接口 编程 咏 ， 当 然 要 定义 接口 了 ， 然 后 看 看 
实现 类 ， 如 代码 清单 20-2 所 示 。 


代码 清单 20-2 项 目 信 息 的 实现 


public class Project implements IProject { 
// 项 目 名 称 
private String name = ""; 
// 项 目 成 员 数 量 
private int num = 0; 











// 项 目 费用 
private int cost = 0; 
// 定 义 一 个 构造 函数 ， 把 所 有 老板 需要 看 到 的 信 ， 忌 存 储 起 来 
public Project(String name,int num,int cost)t{ 
// 赋 值 到 类 的 成 员 变 量 中 
this.name = name; 
this.num = num; 
this.cost=cost,; 




















} 

// 得 到 项 目的 信息 

public String getProjectInfo() { 
String info = ""; 





// 获 得 项 目的 名 称 

info = info+ "项 目 名 称 是 : " + this,name， 
// 获 得 项 目 人 数 

info = info + "Nt 项 目 人 数 : "+ this.num; 
// 项 目 费用 
info = info+ "Nt 项 目 费用 : "+ this.cost 
return info; 

















实现 类 也 是 极度 简单 ， 通 过 构造 函数 把 要 显示 的 数据 传递 过 来 ， 然 
后 放 到 getProjectInfo 中 显示 ， 这 太 容 易 了 ! 然后 我 们 老大 要 看 看 结果 
了 ， 如 代码 清单 20-3 所 示 。 


代码 清单 20-3 老大 看 报表 的 场景 


public class Boss { 
public static void main(String[] args) { 

// 定 义 一 个 List， 存 放 所 有 的 项 目 对 象 
ArrayList<IProject> projectList = new ArrayL 
// 增 加 星球 大 战 项 目 
projectList,add(new Project(" 星 球 大 战 项 目 ", 10 
// 增 加 扭转 时 空 项 目 
projectList,add(new Project(" 扭 转 时 空 项 目 ",100 
// 增 加 超人 改造 项 目 
projectList,add(new Project(" 超 人 改造 项 目 ",100 
// 这 边 100 个 项 目 
for(int i=4;i<104;i++){ 

projectList. add(new Project(" 第 "+i+" 
} 
































// 遍 历 一 下 ArrayList， 把 所 有 的 数据 都 取出 
for(IProject project:projectList)t{ 
System.out.println(project.getProjectIinfo()); 
} 

































































} 
} 
然后 看 一 下 我 们 的 运行 结果 ， 如 下 所 示 : 
项 目 名 称 是 : 星球 大 战 项 目 项 目 人 数 : 10 项 目 费用 : 100000 
项 目 名 称 是 : 扭转 时 空 项 目 项 目 人 数 : 100 项 目 费 用 : 10000000 
项 目 名 称 是 : 超人 改造 项 目 项 目 人 数 : 10000 项 目 费 用 : 1000000000 
项 目 名 称 是 : 第 4 个 项 目 项 目 人 数 : 20 项 目 费 用 : 4000000 
项 目 名 称 是 : 第 5 个 项 目 项 目 人 数 : 25 项 目 费 用 : 5000000 





























老大 一 看 ， 非 常 开心 ， 这 么 快 就 出 结果 了 ， 大 大 地 把 我 夸奖 了 一 
粤 ， 然 后 就 去 埋头 研究 那 堆 枯 燥 的 报表 了 。 我 回 到 座位 上 ， 又 看 了 了 一遍 
时 序 (心里 很 乐 ， 就 又 想 看 看 自己 的 成 果 ) ， 想 想 (一 日 三 省 嘛 ) ， 应 
该 还 有 另外 一 种 实现 方式 ， 因 为 是 遍历 嘛 ， 让 我 想到 的 就 是 Java 的 迭代 
器 接口 java.util.iterator， 它 的 作用 就 是 遍历 Collection 集 合 下 的 元 素 ， 那 
我 们 的 程序 还 可 以 有 另外 一 种 实现 ， 通 过 实现 iterator 接 口 来 实现 遍历 ， 
先 修正 一 下 类 图 ， 如 图 20-2 所 示 。 








java.util.Iterator 
| 


+boolean hasNext() 
+E next() 


+Vold remove() 
<<interface>> 
IProject 
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+String getProjectInfo() 
IProjectlterator 


+void add() 
+IProjectIterator iterator() 
| 


Projectlte rator 
| | 

































图 20-2 增加 友 代 接口 的 类 图 











看 着 是 不 是 复杂 了 很 多 ? 是 的 ， 是 有 点 复杂 了 ， 是 不 是 我 们 把 简单 
的 事情 复杂 化 了 ? 请 读者 继续 阅读 下 去 ， 我 等 会 儿 说 明 原 因 。 我 们 先 分 
析 一 下 我 们 的 类 图 java.util.Iterator 接 口中 声明 了 三 个 方法 ， 这 是 JDK 定 
义 的 ， ProjectIterator 实现 该 接口 ， 并 且 聚 合 了 Project 对 象 ， 也 就 是 把 
Project 对 象 作 为 本 对 象 的 成 员 变量 使 用 。 看 类 图 还 不 是 很 清晰 ， 我 们 一 
起 看 一 下 代码 ， 先 看 IProject 接 口 的 改变 ， 如 代码 清单 20-4 所 示 。 





代码 清单 20-4 项 目 信 息 接口 


public interface IProject { 
// 增 加 项 目 





public void add(String name,int num,int cost); 
// 从 老板 这 里 看 到 的 就 是 项 目 信 息 

public String getProjectInfo( ) ; 

// 获 得 一 个 可 以 被 吉 历 的 对 象 

public IProjectIterator iterator(); 























ww 


这 里 多 了 两 个 方法 ， 一 个 是 add 方 法 ， 这 个 方法 是 增加 项 目 ， 也 就 
是 说 产生 了 一 个 对 象 后 ， 直 接 使 用 add 方 法 增加 项 目 信 息 。 我 们 再 来 看 
其 实现 类 ， 如 代码 清单 20-5 所 示 。 


代码 清单 20-5 项 目 信 息 


public class Project implements IProject { 
// 定 义 一 个 项 目 列表 ， 所 有 的 项 目 都 放 在 这 里 
private ArrayList<IProject> projectList = new ArrayList<IPro 
// 项 目 名 称 
private String name = ""; 
// 项 目 成 员 数 量 
private int num = 0; 
// 项 目 费 用 
private int cost = 0; 
public Project(){ 


























} 

// 定 义 一 个 构造 函数 ， 把 所 有 老板 需要 看 到 的 信息 存储 起 来 
private Project(String name,int num,int cost)t{ 
// 赋 值 到 类 的 成 员 变 量 中 

this.name = name， 

this.num = num; 

this.cost=cost; 














} 

// 增 加 项 目 

public void add(String name,int num,int cost)t{ 
this.projectList.add(new Project(name,num,cost)); 


} 
// 得 到 项 目的 信息 
public String getProjectIinfo() { 














String info = ""; 

// 获 得 项 目的 名 称 

info = info+ "项 目 名 称 是 : " + this,name 
// 获 得 项 目 人 数 


info = info + "Nt 项 目 人 数 : "+ this,.num， 
// 项 目 费用 
info = info+ "Nt 项 目 费 用 : "+ this.cost 
return info; 


} 
// 产 生 一 个 壳 历 对 象 
public IProjectIterator iterator()t{ 
return new ProjectIterator(this,.projectList ) ; 
} 








过 构造 函数 ， 传 递 了 一 个 项 目 所 必需 的 信息 ， 然 后 通过 iterator() 
方法 ， 把 所 有 项 目 都 返回 到 一 个 迭代 器 中 。Iterator() 方 法 看 不 懂 不 要 
紧 ， 继 续 向 下 阅读 。 再 看 IProjectIterator 接 口 ， 如 代码 清单 20-6 所 示 。 
代码 清单 20-6 项 目 迭 代 器 接口 


public interface IProjectIterator extends Iterator { 





大 家 可 能 对 该 接口 感觉 很 奇怪 ， 你 定义 的 这 个 接口 方法 、 变 量 都 没 
有 ， 有 什么 意义 呢 ? 有 意义 ， 所 有 的 Java 书 上 都 会 说 要 面向 接口 编程 ， 
你 的 接口 是 对 一 个 事物 的 描述 ， 也 就 是 说 我 通过 接口 就 知道 这 个 事物 有 
哪些 方法 ， 哪 些 属 性 ， 我 们 这 里 的 IProjectIterator 是 要 建立 一 个 指向 
Project 类 的 迭代 器 ， 目 前 暂时 定义 的 就 是 一 个 通用 的 迭代 器 ， 可 能 以 后 
会 增加 IProjectIterator 的 一 些 属 性 或 者 方法 。 当 然 了 ， 你 也 可 以 在 实现 类 
上 实现 两 个 接口 ， 一 个 是 Iterator, 一 个 是 IProjectIterator 〈 这 时 候 ， 这 个 
接口 融 不 用 继承 Iterator) ， 杀 猪 杀 尾巴 ， 各 有 各 的 杀 法 。 我 的 习惯 是 : 
如 果 我 要 实现 一 个 容器 或 者 其 他 API 提 供 接口 时 ， 我 一 般 都 自己 先 写 一 
个 接口 继承 ， 然 后 再 继承 自己 写 的 接口 ， 保 证 自己 的 实现 类 只 用 实现 自 














己 写 的 接口 (接口 传递 ， 当 然 也 要 实现 顶层 的 接口 ) ， 程 序 阅 读 也 清晰 
一 些 。 我 们 继续 看 迭代 器 的 实现 类 ， 如 代码 清单 20-7 所 示 。 


代码 清单 20-7 项 目 迭 代 器 


public class ProjectIterator implements IProjectIterator { 
// 所 有 的 项 目 都 放 在 ArrayList 中 
private ArrayList<IProject> projectList = new ArrayList<IPro 
private int currentItem = 0; 
// 构 造 函数 传 入 projectList 
public ProjectIterator(ArrayList<IProject> projectList)t{ 
this.projectList = projectList,; 








} 
// 判 断 是 否 还 有 元 素 ， 必 须 实 现 
public boolean hasNext() { 
// 定 义 一 个 返回 值 
boolean b = true; 
if(this.currentIitem>=projectList,.size()||this.projec 
b =false; 





} 


return b; 


} 
// 取 得 下 一 个 值 
public IProject next() { 
return (IProject)this.projectList.get(this.currentIt 


// 删 除 一 个 对 象 
public void remove() { 


// 暂 时 没有 使 用 到 
} 





细心 的 读者 可 能 会 从 代码 中 发 现 一 个 问题 ，java.util.iterator 接 口中 
定义 next0 方 法 的 返回 值 类 型 是 E， 而 你 在 ProjectIterator 中 返回 值 却 是 
IProject，E 和 IProject 有 什么 关系 ? 


E 是 JDK 1.5 中 定义 的 新 类 型 : 元 素 〈Element) ， 是 一 个 泛 型 符 





号 ， 表 示 一 个 类 型 ， 具 体 什么 类 型 是 在 实现 或 运行 时 决定 ， 总 之 它 代表 

的 是 一 种 类 型 ， 你 在 这 个 实现 类 中 把 它 定义 为 ProjectTterator， 在 另外 一 

个 实现 类 可 以 把 它 定 义 为 Sting， 都 没有 问题 。 它 与 Object 这 个 类 可 是 不 

同 的 ，Object 是 所 有 类 的 父 类 ， 随 便 一 个 类 你 都 可 以 把 它 向 上 转型 到 

Object 类 ， 也 只 是 因为 它 是 所 有 类 的 父 类 ， 它 才 是 一 个 通用 类 ， 而 E 是 
个 符号 ， 代 表 所 有 的 类 ， 当 然 也 代表 Object 了 。 














都 写 完毕 了 ， 看 看 我 们 的 Boss 类 有 多 少 改 动 ， 如 代码 清单 20-8 所 


代码 清单 20-8 老板 看 报表 


public class Boss { 
public static void main(String[] args) { 

// 定 义 一 个 List， 存 放 所 有 的 项 目 对 象 

IProject project = new Project(); 

// 增 加 星球 大 战 项 目 

project .add(" 星 球 大 战 项 目 ddddd" ,10,100000 ) ; 

// 增 加 扭转 时 空 项 目 

project.add(" 扭 转 时 空 项 目 ", 100,10000000 ) ; 

// 增 加 超人 改造 项 目 

project ,add(" 超 人 改造 项 目 ",10000,1000000000 ) ; 

// 这 边 100 个 项 目 

for(int i=4;i<104;i++){ 
project.add(" 第 "+i+" 个 项 目 ",i*5,i*100( 


} 
// 遍 历 一 下 ArrayList， 把 所 有 的 数据 都 取出 
IProjectIterator projectIterator = project.i 
while(projectIterator.hasNext())t{ 
IProject p = (IProject)projectIiterat 
System.out.println(p.getProjectInfo( 



































运行 结果 如 下 所 示 : 








项 目 名 称 是 : 星球 大 战 项 目 项 目 人 数 : 10 项 目 费用 : 100000 


(T 




















项 目 名 称 是 : 扭转 时 空 项 目 项 目 人 数 : 100 项 目 费 用 : 10000000 
项 目 名 称 是 : 超人 改造 项 目 项 目 人 数 : 10000 项 目 费 用 : 1000000000 
项 目 名 称 是 : 第 4 个 项 目 项 目 人 数 : 20 项 目 费 用 : 4000000 












































项 目 名 称 是 : 第 5 个 项 目 项 目 人 数 : 25 项 目 费 用 : 5000000 





运行 结果 完全 相同 ， 但 是 上 面 的 程序 复杂 性 增加 了 不 少 ， 难 道 我 们 
退回 到 原始 时 代 了 吗 ? 非 也 ， 非 也 ， 只 是 我 们 回 退 到 JDK 1.0.8 版 本 的 编 
程 时 代 了 ， 我 们 使 用 一 种 新 的 设计 模式 一 一 和 迭代 器 模式 。 


20.2 迭代 器 模式 的 定义 


迭代 堪 模 式 〈Iterator Pattern) 目前 已 经 是 一 个 没落 的 模式 ， 基 本 上 
没 人 会 单独 写 一 个 迭代 器 ， 除 非 是 产品 性 质 的 开发 ， 其 定义 如 下 : 


Provide a way to access the elements of an aggregate object sequentially 
without exposing its underlying representation.〈 它 提供 一 种 方法 访问 一 个 
容器 对 象 中 各 个 元 素 ， 而 又 不 需 暴 露 该 对 象 的 内 部 细节 。 ) 





迭代 器 是 为 容 髓 服务 的 ， 那 什么 是 容 堪 呢 ? 能 容纳 对 象 的 所 有 类 
型 都 可 以 称 之 为 容器 ， 例 如 Collection 集 合 类 型 、Set 类 型 等 ， 迭 代 器 模 
式 束 是 为 解决 遇 历 这 些 容 器 中 的 元 素 而 诞生 的 。 其 通用 类 图 ， 如 图 20-3 
所 示 。 
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+Createlterator() +First() 
+NextO 
+IsDone() 


+Currentltem() 
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i 
图 20-3 迭代 堪 模 式 的 通用 类 图 


和 代 需 模 式 提 供 了 过 历 容 需 的 方便 性 ， 容 器 只 要 管理 增 减 元 素 台 可 
以 了 ， 需 要 过 历时 交 由 迭代 器 进行 。 迭 代 器 模式 正 是 由 于 使 用 得 太 频 
繁 ， 所 以 大 家 才 会 忽略 ， 我 们 来 看 看 迭代 器 模式 中 的 各 个 角色 : 





e@ Iterator 抽 象 迭 代 器 





抽象 迭代 器 负责 定义 访问 和 遍历 元 素 的 接口 ， 而 且 基 本 上 是 有 固定 
的 3 个 方法 : firstO 获 得 第 一 个 元 素 ，next0 访 问 下 一 个 元 系 ，isDone0O 是 


否 已 经 访问 到 底部 《Java 叫 做 hasNext() 方 法 ) 。 











e@ Concretelterator 具 体 迭 代 器 





具体 迭代 器 角色 要 实现 迭代 器 接口 ， 完 成 容器 元 素 的 裔 历 。 
e Aggregate 抽 象 容器 


容器 角色 负责 提供 创建 具体 迭代 器 角色 的 接口 ， 必 然 提供 一 个 类 似 
createIterator() 这 样 的 方法 ， 在 Java 中 一 般 是 iterator() 方 法 。 


e Concrete Aggregate 具 体 容 器 





具体 容器 实现 容器 接口 定义 的 方法 ， 创 建 出 容纳 迭代 器 的 对 象 。 





我 们 来 看 迭代 喜 模 式 的 通用 源 代 码 ， 先 看 抽象 欠 代 器 Iterator， 如 代 
码 清单 20-9 所 示 。 


代码 清单 20-9 抽象 迭代 器 


public interface Iterator { 
// 遍 历 到 下 一 个 元 素 
public Object next(); 
// 是 否 已 经 遍历 到 尾部 
public boolean hasNext(); 
// 删 除 当 前 指向 的 元 素 
public boolean remove( ) ; 




















具体 迭代 器 如 代码 清单 20-10 所 示 。 


代码 清单 20-10 具体 迭代 器 


public class ConcreteIterator implements Iterator { 
private Vector vector = new Vector(); 
// 定 义 当 前 游标 
public int cursor = 0; 





@SuppressWarnings("unchecked") 
public ConcreteIterator(Vector _vector)t{ 
this.vector = _vector,; 


} 
// 判 断 是 否 到 达 尾部 
public boolean hasNext() { 
if(this.cursor == this.vector.size())t{ 
return false; 
}elsef 
return true; 
} 


} 
// 返 回 下 一 个 元 素 
public Object next() { 
Object result = null; 
if(this.hasNext())t{ 
result = this.vector.get(this.cursor++); 
}elsef 
result = null; 
} 


return result; 


} 

// 删 除 当 前 元 素 

public boolean remove() { 
this.vector.remove(this.cursor); 
return true; 








注意 ”开发 系统 时 ， 友 代 嚣 的 删除 方法 应 该 完成 两 个 逻辑 : 一 是 
删除 当前 元 系 ， 二 是 当前 游标 指向 下 一 个 元 素 。 





抽象 容 圳 如 代码 清单 20-11 所 示 。 


代码 清单 20-11 抽象 容器 


public interface Aggregate { 
// 是 容器 必然 有 元 素 的 增加 
public void add(Object object); 
// 减 少 元 素 





public void remove(Object object ) ; 
// 由 迭代 器 来 遍历 所 有 的 元 素 


public Iterator iterator(); 


























具体 容器 如 代码 清单 20-12 所 示 。 


代码 清单 20-12 具体 容器 


public class ConcreteAggregate implements Aggregate { 
// 容 纳 对 象 的 容器 
private Vector Vector = new Vector () ; 
// 增 加 一 个 元 素 
public void add(Object object) { 
this.vector.add(object); 


} 
// 返 回 和 迭代 器 对 象 
public Iterator iterator() { 
return new ConcreteIterator(this.vector); 











} 

// 删 除 一 个 元 素 
public void remove(Object object) { 
this.remove(object); 

} 


场景 类 如 代码 清单 20-13 所 示 。 


代码 清单 20-13 场景 类 


public class Client { 
public static void main(String[] args) { 


// 声 明 出 容器 
Aggregate agg = new ConcreteAggregate( ) ; 
// 产 生 对 象 数 据 放 进去 


agg.add("abc"); 

agg.add("aaa" ); 

agg.add("1234"); 

// 授 历 一 下 

Iterator iterator = agg.iterator(); 

while(iterator.hasNext())t{ 
System.out.println(iterator.next()); 


简单 地 说 ， 迭 代 怖 就 类 似 于 一 个 数据 库 中 的 游标 ， 可 以 在 一 个 容器 
内 上 下 翻滚 ， 遍 历 所 有 它 需 要 查看 的 元 素 。 





20.3 友人 代 器 模式 的 应 用 


我 们 在 例子 中 使 用 了 迭代 器 模式 后 为 什么 使 原本 简单 的 应 用 变 得 复 
杂 起 来 了 呢 ? 那 是 因为 我 们 在 简单 的 应 用 中 使 用 了 和 迭代 妖 ， 在 哪 ? 请 看 
代码 清单 20-3， 注 意 这 段 话 : for(IProject project:projectList)， 它 为 什么 
能 够 运行 起 来 ? 还 不 是 因为 ArrayList 已 经 实现 了 iterator0) 方 法 ， 我 们 才 
能 如 此 简单 地 应 用 。 


从 JDK 1.2 版 本 开始 增加 java.util.Iterator 这 个 接口 ， 并 逐步 把 Iterator 
应 用 到 各 个 聚集 类 (Collection〉 中， 我 们 来 看 JDK 1.5 的 API 帮 助 文件 ， 
你 会 看 到 有 一 个 叫 java.util.Iterable 的 接口 ， 看 看 有 多 少 个 接口 继承 了 
ES 
BeanContext,BeanContextServices,BlockingQueue<E>,Collection<E>,List<E 
再 看 看 有 它 多 少 个 实现 类 : 
AbstractCollection, AbstractList, AbstractQueue, AbstractSequentialList, Abstra 


基本 上 我 们 经 常 使 用 的 类 都 在 这 个 表 中 了 ， 也 下 是 因为 Java 把 达 代 器 模 
式 已 经 融入 到 基本 API 中 了 ， 我 们 才能 如 此 轻松 、 便 捷 。 





我 们 再 来 看 看 Iterable 接 口 。java.util.Iterable 接 口 只 有 一 个 方法 : 
iterator0， 也 束 说 ， 通 过 iterator(O 这 个 方法 去 壳 历 聚集 类 中 的 所 有 方法 或 
属性 ， 基 本 上 现在 所 有 的 高 级 语言 都 有 Iterator 这 个 接口 或 者 实现 ，Java 





己 经 把 迭代 器 给 我 们 准备 好 了 ， 我 们 再 去 写 迭 代 器 ， 就 有 点 多 余 了 。 所 
以 呀 ， 这 个 和 迭代 器 模式 也 有 点 没 沙 了 ， 基 本 上 很 少 有 项 目 再 独立 写 迭 代 
器 了 ， 直 接 使 用 Collection 下 的 实现 类 就 可 以 完美 地 解雇 问题 。 





迭代 器 现在 应 用 得 越 来 越 广泛 了 ， 甚 至 已 经 成 为 一 个 最 基础 的 工 
具 。 一 些 大 师 级 人 物 其 至 建议 把 迭代 堪 模 式 从 23 个 模式 中 删除 ， 为 什么 
呢 ? 就 是 因为 现在 它 太 普通 了 ， 已 经 融入 到 各 个 语言 和 工具 中 了 ， 比 如 
PHP 中 你 能 找到 它 的 身影 ，Penl 也 有 和 它 的 存在 ， 甚 至 是 前 台 的 页 面 技术 
AJAX 也 可 以 有 它 的 出 现 〈 如 在 Struts2 中 就 可 以 直接 使 用 iterator) 。 基 
本 上 ， 只 要 你 不 是 在 使 用 那些 古董 级 〈 指 版 本 号 ) 的 编程 语言 的 话 ， 都 
不 用 自己 动手 写 迭 代 器 。 














20.4 最 佳 实践 





如 果 你 是 做 Java 开 发 ， 尽 量 不 要 自己 写 迭 代 器 模式 ! 省 省 吧 ， 使 用 
Java 提 供 的 Iterator 一 般 就 能 满足 你 的 要 求 了 。 


71 党 衣 辣 仿 趣 


21.1 公司 的 人 事 架 构 是 这 样 的 吗 








各 位 读者 ， 大 家 在 上 学 的 时 候 应 该 都 学 过 “数据 结构 ”这 门 课程 吧 ， 
还 记得 其 中 有 一 市 叫 “ 二 叉 树 * 吧 ， 我 们 上 学 那 会 儿 这 一 章节 是 必 考 内 
容 ， 左 子 树 ， 右 子 树 ， 什 么 先 厅 所 历 、 后 序 吉 历 ， 重 点 就 是 二 叉 树 的 志 
历 ， 我 还 记得 当时 老师 就 次， 考试 的 时 候 一 定 有 二 又 树 的 构建 和 通 历 ， 
见 在 想起 来 还 是 觉得 老师 是 正确 的 ， 树 状 结构 在 实际 中 应 用 非常 广泛 ， 
第 























虽 就 先 说 个 最 常见 的 例子 ， 公 司 的 人 事 管 理 就 是 一 个 典型 的 树 状 结 


构 ， 想 想 看 你 公司 的 组 织 架 构 是 不 是 如 图 21-1 所 示 。 



































































































































从 最 高 的 老大 ， 往 下 一 层 一 层 的 管理 ， 最 后 到 我 们 这 层 小 兵 .…… 很 
典型 的 树 状 结构 〈 说 明 一 下 ， 这 不 是 二 又 树 ， 有 关 二 又 树 的 定义 可 以 翻 
翻 以 前 的 教科 书 ) ， 我 们 今天 的 任务 就 是 要 把 这 个 树 状 结构 实现 出 来 ， 
并 且 还 要 把 它 过 历 一 过 ， 就 类 似 于 阅读 你 公司 的 人 员 人 花 名 册 。 


从 该 树 状 结构 上 分 析 ， 有 两 种 不 同性 质 的 节点 : 有 分 支 的 节点 《如 
研发 部 经 理 ) 和 无 分 文 的 节点 〈 如 员工 A、 员 工 D 等 ) ， 我 们 增加 一 点 
学 术 术 语 上 去 ， 总 经 理 叫 做 根 节 点 (是 不 是 想到 XML 中 的 那个 根 节点 
root， 那 就 对 了 )， 类 似 研发 部 经 理 有 分 文 的 市 点 叫做 树 校 节点 ， 类 似 员 
工 A 的 无 分 文 的 节点 叫做 树叶 市 点 ， 都 很 形象 ， 三 个 类 型 的 节点 ， 那 是 





不 是 定义 三 个 类 就 可 以 ? 好 ， 我 们 按照 这 个 思路 走 下 去 ， 先 看 我 们 目 己 
设计 的 类 图 ， 如 图 21-2 所 示 。 





根 节点 、 树叶 节点 
<<interface>> 
IRoot 
+String getInfo() +String getInfo() +String getInfo() 


+vold add(IBranch branch) +void add(IBranch branch) 
+void add(ILeaf leaf) +void add(ILeaf leaf) 
+ArrayList getSubordinateInfo() +ArrayList getSubordinateInfo() 











图 21-2 最 容易 想到 的 组 织 架 构 类 图 








这 个 类 图 是 初学 者 最 容易 想到 的 类 图 (首先 声明 ， 这 个 类 图 是 有 缺 
陷 的 ， 如 果 你 已 经 看 明白 这 个 类 图 的 缺陷 了 ， 该 段落 就 可 以 一 目 十 行 地 
看 下 去 ， 我 们 是 循序 渐进 地 讲 诗 ， 一 步 一 个 脚印 ) ， 非 党 简单 ， 我 们 来 
看 一 下 如 何 实现 ， 先 看 最 高 级 别 的 根 节 点 接口 ， 如 代码 清单 21-1 所 示 。 


代码 清单 21-1 根 节 点 接口 


public interface IRoot { 














// 得 到 总 经 理 的 信息 
public String getInfo() 

// 总 经 理 下 边 要 有 小 兵 ， 那 要 能 增加 小 兵 ， 比 如 研发 部 总 经 理 ， 这 是 个 树 校 节点 
public void add(IBranch branch ) ; 

// 那 要 能 增加 树叶 节点 

public void add(ILeaf leaf) ; 

// 既 然 能 增加 ， 那 还 要 能 够 遍历 ， 不 可 能 总 经 理 不 知道 他 手下 有 哪些 人 
public ArrayList getSubordinateInfo( ) ; 
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这 个 根 节 点 的 对 象 就 是 我 们 的 总 经 理 ， 其 具体 实现 如 代码 清单 21-2 
所 示 。 


代码 清单 21-2 根 节点 的 实现 


public class Root implements IRoot { 
// 保 存根 节点 下 的 树枝 节点 和 树叶 节点 ，Subordinate 的 意思 是 下 级 
private ArrayList subordinateList = new ArrayList(); 
// 根 节点 的 名 称 
private String name = ""; 
// 根 节点 的 职位 
private String position = ""; 
// 根 节点 的 薪水 
private int salary = 0; 
// 通 过 构造 函数 传递 进来 总 经 理 的 信息 
public Root(String name,String position,int salary)t 
this.name = name， 
this.position = position; 
this.salary = salary; 


} 

// 增 加 树枝 节点 

public void add(IBranch branch) { 
this.subordinateList.add(branch); 


} 

// 增 加 叶子 节点 ， 比 如 秘书 ， 直 接 隶 属于 总 经 理 
public void add(ILeaf leaf) { 
this.subordinateList.add(leaf ); 













































































} 
// 得 到 自己 的 信息 
public String getInfo() { 
String info = ""; 
info = "名 称 : "+ this.name;;， 
info = info + "Nt 职位 : " + this.position; 
info = info + "Nt 薪水 : " + this.salary; 





return Info 





} 

// 得 到 下 级 的 信息 

public ArrayList getSubordinateInfo() { 
return this.subordinateList,; 

} 


很 简单 ， 通 过 构造 函数 传 入 参数 ， 然 后 获得 信息 ， 可 以 增加 子 树枝 
节点 (部 门 经 理 ) 和 叶子 节点 (秘书 ) 。 我 们 再 来 看 其 他 有 分 支 的 节点 
接口 ， 如 代码 清单 21-3 所 示 。 











代码 清单 21-3 其 他 有 分 支 的 节点 接口 


public interface IBranch { 
// 获 得 信息 
public String getInfo(); 
// 增 加 数据 节点 ， 例 如 研发 部 下 设 的 研发 一 
public void add(IBranch branch ) ; 











// 增 加 叶子 节点 

public void add(ILeaf leaf ); 

// 获 得 下 级 信息 

public ArrayList getSubordinateInfo( ) ， 
} 

有 了 接口 ， 就 应 该 有 实现 ， 其 具体 的 实现 关 ， 如 代码 清单 21-4 所 
不 。 


代码 清单 21-4 分 支 的 市 点 实现 


public class Branch implements IBranch { 


// 存 储 子 节 点 的 信息 

private ArrayList subordinateList = new ArrayList(); 
// 树 村 节 点 的 名 称 

private String name="",，; 

// 树 村 节点 的 职位 

private String position = ""; 


// 树 枝 节 点 的 薪水 





private int salary = 0; 

// 通 过 构造 函数 传递 树枝 节点 的 参数 

public Branch(String name,String position,int salary)t{ 
this.name = name， 
this.position = position; 
this.salary = salary; 


} 

// 增 加 一 个 子 树枝 节点 

public void add(IBranch branch) { 
this.subordinateList.add(branch); 








} 

// 增 加 一 个 叶子 节点 

public void add(ILeaf leaf) { 
this.subordinateList.add(leaf ); 


} 
// 获 得 自己 树 校 节 点 的 信息 
public String getInfo() { 
String info = ""; 
info = "名 称 : " + this,name， 
info = info + "Nt 职位 : "+ this.position; 
info = info + "Nt 薪水 : "+this,salary; 
return Info ， 











} 

// 获 得 下 级 的 信息 

public ArrayList getSubordinateInfo() { 
return this.subordinateList; 











} 
不 管 是 总 经 理 还 是 部 门 经 理 都 是 有 子 节点 的 存在 ， 最 终 的 子 节点 就 
是 叶子 节点 ， 其 接口 如 代码 清单 21-5 所 示 。 


代码 清单 21-5 叶子 市 点 的 接口 


public interface ILeaf { 
// 获 得 自己 的 信息 
public String getInfo(); 

















叶子 市 点 的 接口 简单 ， 实 现 也 非 第 容易 ， 如 代码 清单 21-6 所 示 。 


代码 清单 21-6 叶子 节点 的 实现 


public class Leaf implements ILeaf { 

// 叶 子 叫 什么 名 字 

private String name = ""; 

// 叶 子 的 职位 

private String position = ""; 

// 叶 子 的 薪水 

private int Sa 0; 

// 通 过 构造 函数 传递 信息 

public Leaf(String name,String position,int salary)t 
this.name = name， 
this.position = position; 
this.salary = salary; 























} 
// 最 小 的 小 兵 只 能 获得 自己 的 信息 了 
public String getInfo() { 





String info = ""， 
info = "名 称 : " + this,name， 
info = info + "Nt 职位 : "+ this.position; 


info + "Nt 薪水 : "+this.salary; 
return Info 





好 了 ， 所 有 的 根 节点 、 树 校 节 点 和 叶子 节点 都 已 经 实现 了 ， 从 总 经 
理 、 部 门 经 理 到 最 终 的 员工 都 已 经 实现 ， 然 后 的 工作 就 是 组 装 成 一 个 树 
状 结构 并 遍历 这 棵 树 ， 通 过 什么 来 完成 昵 ? 通过 场景 类 Client 完 成 ， 如 
代码 清单 21-7 所 示 。 








代码 清单 21-7 场景 类 


public class Client { 
public static void main(String[|] args) { 

// 首 先 产生 了 一 个 根 节点 
IRoot ceo = new Root(" 王 大 麻子 ", "总 经 理 ", 100000); 
// 产 生 三 个 部 门 经 理 ， 也 就 是 树枝 节点 
IBranch developDep = new Branch(" 刘 大 桨 子 ", "研发 部 门 经 天 
IBranch salesDep = new Branch(" 马 二 拐子 ", "销售 部 门 经 理 ", 
IBranch financeDep = new Branch(" 赵 三 驼 子 ", "财务 部 经 理 " 










































































// 再 把 三 个 小 组 长 产生 出 来 

IBranch firstDevGroup = new Branch(" 杨 三 也 斜 ", "开发 一 组 
IBranch secondDevGroup = new Branch(" 吴 大 棒 杷 ", "开发 二 
// 剩 下 的 就 是 我 们 这 些小 兵 了 ，, 就 是 路 人 甲 、 路 人 乙 








ILeaf a = new Leaf("a", "开发 人 员 ",2000); 
ILeaf b = new Leaf("b", "开发 人 员 ",2000); 
ILeaf c = new Leaf("c", "开发 人 员 ", 2000); 
ILeaf d = new Leaf("d", "开发 人 员 ",2000); 
ILeaf e = new Leaf("e", "开发 人 员 ",2000); 
ILeaf f = new Leaf("f", "开发 人 员 ",2000); 
ILeaf g = new Leaf("g", "开发 人 员 ",2000); 
ILeaf h = new Leaf("h", "销售 人 员 ", 5000); 
ILeaf i = new Leaf("i", "销售 人 员 ", 4000); 
ILeaf j = new Leaf("j", "财务 人 员 ", 5000); 
ILeaf k = new Leaf("k", "CEO 秘 书 ", 8000); 














ILeaf zhengLaoLiu = new Leaf(" 郑 老 六 ", "研发 部 副 总 ", 200C 
// 该 产生 的 人 都 产生 出 来 了 ， 然 后 我 们 怎么 组 装 这 棵 树 

// 首 先是 定义 总 经 理 下 有 三 个 部 门 经 理 
ceo.add(developDep); 
ceo.add(salesDep); 
ceo.add(financeDep ) ， 

// 总 经 理 下 还 有 一 个 秘书 
ceo.add(k); 

// 定 义 研 发 部 门下 的 结构 
developDep.add(firstDevGroup); 
developDep.add(secondDevGroup); 

// 研 发 部 经 理 下 还 有 一 个 副 总 
developDep.add(zhengLaoLiu); 

// 看 看 开发 两 个 开发 小 组 下 有 什么 

firstDevGroup.add(a); 

firstDevGroup.add(b); 

firstDevGroup.add(c); 

secondDevGroup.add(d); 

secondDevGroup.add(e); 

secondDevGroup.add(f); 

// 再 看 销售 部 下 的 人 员 情 况 

salesDep.add(h); 

salesDep.add(i); 

// 最 后 一 个 财务 

financeDep.add(]j); 

// 打 印 写 完 的 树 状 结构 
System.out.println(ceo.getIinfo()); 

// 打 印 出 来 整个 树 形 
getAllSubordinateInfo(ceo.getSubordinateInfo()); 


} 

// 遍 历 所 有 的 树枝 节点 ， 打 印 出 信息 
private static void getAllSubordinateInfo(ArrayList subordin 
int length = subordinatelist.sizel(); 



































































































































// 定 义 一 个 ArrayList 长 度 ， 不 要 在 for 循 环 中 每 次 计算 
for(int m=0;m<length;m++){ 
Object s = subordinateList.get(m); 
if(s instanceof Leaf){  // 是 个 叶子 节点 ， 也 就 是 员工 
ILeaf employee = (ILeaf)s; 
System.out.println(((Leaf) s).getIinfo() 





}elsef 


IBranch branch = (IBranch)s; 
System.out.println(branch.getInfo()); 


// 再 递归 调用 


getAllSubordinateInfo(branch.getSubordi 


这 个 程序 比较 长 ， 如 果 在 我 们 的 项 目 中 有 这 样 的 程序 ， 肯 定 是 要 说 
拉 出 来 做 典型 的 ， 你 写 一 大 坨 的 程序 给 谁 蚜 ， 以 后 还 要 维护 ， 程 序 要 短 
小 精怪 ! 幸运 的 是 ， 我 们 这 是 作为 案例 来 讲解 ， 而 且 就 是 指出 这 样 组 凌 
这 标 树 是 有 问题 的 ， 等 会 我 们 深入 讲解 ， 先 看 运行 结果 : 


名 称 : 
名 称 : 
名 称 : 
名 称 : 
名 称 : 
名 称 : 
名 称 : 
名 称 : 
名 称 : 
名 称 : 
名 称 : 
名 称 : 
名 称 : 
名 称 : 





王 大 打 子 
刘 大 病 子 
杨 三 也 和 斜 
d 
b 
C 
吴 大 棒 相 
d 
e 
f 
郑 老 六 
马 二 拐子 
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只 位 : 
职位 : 
只 位 : 
职位 : 
只 位 : 
职位 : 
只 位 : 
只 位 : 
只 位 : 
只 位 : 
只 位 : 
只 位 : 
只 位 : 
只 位 : 


总 经 理 
研发 部 门 经 理 
天 发 二 组 组 长 
开发 人 员 
开发 人 员 
开发 人 员 
开发 三 弓 组 长 
开发 人 员 
开发 人 员 
开发 人 员 
研发 部 副 总 
销售 部 门 经 理 
销售 人 员 
销售 人 员 


薪水 : 100000 


薪水 : 
薪水 : 
薪水 : 
薪水 : 
薪水 : 
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薪水 : 
薪水 : 
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薪水 : 
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薪水 : 


10000 
5000 
2000 
2000 
2000 
6000 
2000 
2000 
2000 
20000 
20000 
5000 
4000 


名 称 : 赵 三 驼 子 ”职位 : 财务 部 经 理 薪水 : 30000 


名 称 : j 只 位 : 财务 人 员 薪水 : 5000 
名 称 : k 只 位 :CEO 秘书 薪水 : 8000 


和 我 们 期 望 的 结果 一 样 ， 一 标 完 整 的 树 束 生成 了 ， 而 且 我 们 还 能 够 
人 裔 历 。 不 错 ， 不 错 ， 但 是 看 类 图 或 程序 的 时 候 ， 你 有 没有 发 觉 有 问题 ? 
getInfo 每 个 接口 都 有 ， 为 什么 不 能 抽象 出 来 ? Root 类 和 Branch 类 有 什么 
关 别 ? 根 节 点 本 身 就 是 树 校 节点 的 一 种 ， 为 什么 要 定义 成 两 个 接口 两 个 
类 ?如 果 我 要 加 一 个 任职 期 限 ， 你 是 不 是 每 个 类 都 需要 修改 ?” 如 采 我 要 
后 序 吉 历 〈 从 员工 找到 他 的 上 级 领导 〉 能 做 到 吗 ? 彻 撒 晕 沫 了 ! 


























问题 很 多 ， 我 们 一 个 一 个 解决 ， 先 说 抽象 的 问题 。 我 们 确实 可 以 把 
IBranch 和 IRoot 合 并 成 一 个 接口 ， 确 认 无 疑 的 事 我 们 先 做 ， 那 我 们 就 修 
改 一 下 类 图 ， 如 图 21-3 所 示 。 


仔细 看 看 这 个 类 图 ， 还 能 不 能 发 现 点 问题 。 想 想 看 接口 的 作用 是 什 
么 ? 定义 一 类 事物 所 具有 的 共性 ， 那 ILeaf 和 IBranch 是 不 是 也 有 共性 
呢 ? 有 ，getImfo 方 法 ! 我 们 是 不 是 要 把 这 个 共性 也 封装 起 来 呢 ? 是 的 ， 
是 的 ， 提 和 炼 事物 的 共同 点 ， 然 后 封装 之 ， 这 是 我 们 作为 设计 专家 的 拿手 
好 戏 ， 修 改 后 的 类 图 如 图 21-4 所 示 。 








<<interface>> : <<interface>> 
IBranch < ILeaf 
Ess======34 


[ss 
+String getInfo() +String getInfo() 
+void add(IBranch branch) 
+void add(ILeaf leaf) 
+ArrayList getSubordinateInfo() 











图 21-3 整合 根 节 点 和 树 术 节点 后 的 类 图 


<<interface>> 
ICorp 
+String getInfo() 


<<Interface>> 
ILeaf 

















图 21-4 修改 后 的 类 图 


类 图 上 增加 了 一 个 ICorp 接 口 ， 它 是 公司 所 有 人 员 信 息 的 接口 类 ， 
不 管 你 是 经 理 还 是 员工 ， 你 部 有 名 字 、 职 位、 薪水 ， 这 个 定义 成 一 个 接 
口 没有 错 ， 但 是 你 可 能 对 于 ILeaf 接 口 持 怀 疑 状态 ， 空 接口 有 何 意义 呀 ? 
有 意义 ! 它 是 每 个 树 术 节点 的 代表 ， 系 统 扩容 的 时 候 你 就 会 发 现 它 是 多 
么 “栋梁 ”。 我 们 先 来 看 新 增加 的 接口 ICorp， 如 代码 清单 21-8 所 示 。 








< 


代码 清单 21-8 公司 人 员 接 口 


public interface ICorp { 
// 每 个 员工 都 有 信息 ， 你 想 隐藏 ， 门 儿 都 没有 ! 





public String getInfo( ) ， 


接口 很 简单 ， 只 有 一 个 方法 ， 束 是 获得 员工 的 信息 ， 树 叶 节 点 
基层 的 构件 ， 我 们 先 来 看 看 它 的 接口 ， 空 接口 ， 如 代码 清单 21-9 所 示 。 





代码 清单 21-9 树叶 接口 


public interface ILeaf extends ICorp { 


l 





树叶 接口 的 实现 类 ， 如 代码 清单 21-10 所 示 。 


代码 清单 21-10 树叶 接口 


public class Leaf implements ILeaf { 

// 小 兵 也 有 名 称 

private String name = ""; 

// 小 兵 也 有 职位 

private String position = ""; 

// 小 兵 也 有 薪水 ， 否 则 谁 给 你 干 

private int salary = 0; 

// 通 过 一 个 构造 函数 传递 小 兵 的 信息 

public Leaf(String name,String position,int salary)t 
this.name = name， 
this.position = position; 
this.salary = salary; 














} 
// 获 得 小 兵 的 信息 
public String getInfo() { 
String info = ""， 
info = "姓名 : " + this.name; 
info = info + "Nt 职位 : "+ this.position; 
info = info + "Nt 薪水 : " + this.salary， 
return Info 











小 兵 就 只 有 这 些 信息 了 ， 我 们 是 具体 干 活 的 ， 我 们 是 管理 不 了 其 他 


同事 的 ， 我 们 来 看 看 那些 经 理 和 小 组 长 是 怎么 实现 的 ， 也 就 是 IBranch 
接口 ， 如 代码 清单 21-11 所 示 。 





代码 清单 21-11 树枝 接口 


public interface IBranch extends ICorp { 

// 能 够 增加 小 兵 ( 树 叶 节 点 ) 或 者 是 经 理 〈 树 枝 节 点 ) 

public void addSubordinate(ICorp corp); 

// 我 还 要 能 够 获得 下 属 的 信息 

public ArrayList<ICorp> getSubordinate( ); 

/* 本 来 还 应 该 有 一 个 方法 delSubordinate(ICorp corp)， 删除 下 属 
* 这 个 方法 我 们 没有 用 到 就 不 写 进来 了 
*/ 





















































uy 














接口 也 很 简单 ， 其 实现 类 也 不 可 能 太 复 洒 ， 如 代码 清单 21-12 所 


代码 清单 21-12 树枝 实现 类 


public class Branch implements IBranch { 

// 领 导 也 是 人 ， 也 有 名 字 

private String name = ""; 

// 领 导 和 领导 不 同 ， 也 是 职位 区 别 

private String position = ""; 

// 领 导 也 是 拿 薪 水 的 

private int salary = 0; 

// 领 导 下 边 有 哪些 下 级 领导 和 小 兵 

ArrayList<ICorp> subordinateList = new ArrayList<ICorp>(); 

// 通 过 构造 函数 传递 领导 的 信息 

public Branch(String name,String position,int salary)t{ 
this.name = name， 
this.position = position; 
this.salary = salary; 


} 

// 增 加 一 个 下 属 ， 可 能 是 小 头目 ， 也 可 能 是 个 小 兵 
public void addSubordinate(ICorp corp) { 
this.subordinateList.add(corp); 


} 
// 我 有 哪些 下 属 



































public ArrayList<ICorp> getSubordinate() { 
return this.subordinateList; 


领导 也 是 人 ， 他 也 有 信息 
ee String getInfol() { 





String info = ""， 
info = "姓名 : " + this.name; 
info = info + "Nt 职位 : "+ this.position; 


info + "Nt 薪水 : " + this.salary; 
return Info ， 














实现 类 也 很 简单 ， 不 多 说 ， 程 序 写 得 好 不 好 ， 就 看 别人 怎么 调用 
了 ， 我 们 看 场景 类 Client， 如 代码 清单 21-13 所 示 。 


代码 清单 21-13 场景 类 a 


public class Client { 
public static void main(String[|] args) { 
// 首 先是 组 装 一 个 组 织 结构 出 来 
Branch ceo = 他 让 全 和 
// 首 先 把 CE0 的 信息 打印 出 来 
out. a getInfo()); 
eye bom out. er 


} 

// 把 整个 树 组 装 出 来 

public static Branch compositeCorpTree( ){ 
// 首 先 产 生 总 经 理 CEO 
Branch root = new Branch(" 王 大 麻子 ", "总 经 理 ", 100000); 
// 把 三 个 部 门 经 理 产 生出 来 
Branch developDep = new Branch(" 刘 大 痪 子 ", "研发 部 门 经 理 
Branch salesDep = new Branch(" 马 二 拐子 ", "销售 部 门 经 理 ",: 
Branch financeDep = new Branch(" 赵 三 弦子 ", "财务 部 经 理 "， 
// 再 把 三 个 小 组 长 产生 出 来 
Branch firstDevGroup = new Branch(" 杨 三 也 斜 ", "开发 一 组 
Branch secondDevGroup = new Branch(" 吴 大 棱 想 ", "开发 二 组 
// 把 所 有 的 小 兵 都 产生 出 来 




















































































































Leaf a = new Leaf("a", "开发 人 员 ",2000); 
Leaf b = new Leaf("b", "开发 人 员 ",2000); 
Leaf c = new Leaf("c", "开发 人 员 ",2000); 
Leaf d = new Leaf("d", "开发 人 员 ",2000); 
Leaf e = new Leaf("e", "开发 人 员 ",2000); 





Leaf f = new Leaf("f", "开发 人 员 ", 2000); 
Leaf g = new Leaf("g", "开发 人 员 ", 2000 ) ; 
Leaf h = new Leaf("h", "销售 人 员 ", 5000); 
Leaf i = new Leaf("i", "销售 人 员 ", 4000 ) ; 
Leaf j = new Leaf("j", "财务 人 员 ", 5000); 
Leaf k = new Leaf("k", "CEO 秘 书 ", 8000); 




















Leaf zhengLaoLiu = new Leaf(" 郑 老 六 ", "研发 部 副 经 理 ", 200 
// 开 始 组 装 

//CE0 下 有 三 个 部 门 经 理 和 一 个 秘书 

root.addSubordinate(k); 
root.addSubordinate(developDep); 

root .addSubordinate(SalesDep ) ， 

root .addSubordinate(financeDep ) ， 

// 研 发 部 经 理 
developDep.addSubordinate(zhengLaoLiu); 
developDep.addSubordinate(firstDevGroup); 
developDep.addSubordinate(secondDevGroup); 
// 看 看 两 个 开发 小 组 下 有 什么 
firstDevGroup.addSubordinate(a); 
firstDevGroup.addSubordinate(b); 
firstDevGroup.addSubordinate(c); 
secondDevGroup.addSubordinate(d); 
secondDevGroup.addSubordinate(e); 
secondDevGroup.addSubordinate(f); 

// 再 看 销售 部 下 的 人 员 情 况 
salesDep.addSubordinate(h); 
salesDep.addSubordinate(i); 

// 最 后 一 个 财务 

financeDep.addSubordinate(]j); 

return root; 


} 
// 裔 历 整 棵 树 , 只 要 给 我 根 节点 ， 我 就 能 遍历 出 所 有 的 节点 
public static String getTreeInfo(Branch root){ 
ArrayList<ICorp> subordinateList = root.getSubordina 
String info = ""， 
for(ICorp s :subordinateList){ 
if(s instanceof Leaf){ // 是 员工 就 直接 获得 信息 
info = info + s.getIinfo()+"\n"; 
}else{ // 是 个 小 头目 
info = info + S.getInfo() +"\n"+ get 
} 
} 


return info; 



















































































运行 结果 完全 相同 ， 不 再 痪 述 。 通 过 这 样 构件 ， 一 个 非常 清晰 的 树 
状 人 员 资 源 管理 图 出 现 了 ， 那 我 们 的 程序 是 否 还 可 以 优化 ? 可 以 ! 你 看 
Leaf 和 Branch 中 都 有 getInfo 信 息 ， 是 不 是 可 以 抽象 ? 好 ， 我 们 抽象 一 
下 ， 如 图 21-5 所 示 。 
















Client 


+Strng getInfo() 








Branch 





+void addSubordinate(Corp corp) 
+ArrayList getSubordinateInfo() 


图 21-5 精简 的 类 图 


你 一 看 这 个 图 ， 乐 了 。 能 不 乐 嘛 ， 减 少 很 多 工作 量 了 ， 接 口 没有 
了 ， 改 成 抽象 类 了 ，IBranch 接 口 也 没有 了 ， 直 接 把 方法 放 到 了 实现 类 
中 了 ， 太 精简 了 ! 而 且 场 景 类 只 认定 抽象 类 Corp 就 成 ， 那 我 们 首先 来 看 
抽象 类 ICorp， 如 代码 清单 21-14 所 示 。 








代码 清单 21-14 抽象 公司 职员 类 


public abstract class Corp { 
// 公 司 每 个 人 都 有 名 称 
private String name = ""; 
// 公 司 每 个 人 都 职位 
private String position = ""; 
// 公 司 每 个 人 都 有 薪水 
private int Salary =0; 








public Corp(String _name,String _position,int _salary)t 


this.name = _name; 
this.position = _position; 
this.salary = _salary; 





// 获 得 员工 信息 
public String getInfo(){ 
String info = ""; 
info = "姓名 : " + this.name; 
info = info + "Nt 职位 : "+ this.position; 
info = info + "Nt 薪水 : " + this.salary， 
return Info ， 











抽象 类 嘛 ， 就 应 该 抽象 出 一 些 共性 的 东西 出 来 ， 然 后 看 两 个 具体 的 
实现 类 ， 树 叶 贡 点 如 代码 清单 21-15 所 示 。 


代码 清单 21-15 树叶 节点 


public class Leaf extends Corp { 
// 就 写 一 个 构造 函数 ， 这 个 是 必需 的 
public Leaf(String _name,String _position,int _salary)t 
super(_name,_position,_salary); 
} 





这 个 精简 得 比较 多 ， 几 行 代码 残 完成 了 ， 确 实 就 应 该 这 样 ， 下 面 是 
小 头目 的 实现 类 ， 如 代码 清单 21-16 所 示 。 


代码 清单 21-16 树枝 节点 


public class Branch extends Corp { 
// 领 导 下 边 有 哪些 下 级 领导 和 小 兵 
ArrayList<Corp> subordinateList = new ArrayList<Corp>(); 
// 构 造 函 数 是 必需 的 
public Branch(String _name,String _position,int _salary)t{ 
super(_name,_position,_salary); 














} 
// 增 加 一 个 下 属 ， 可 能 是 小 头目 ， 也 可 能 是 个 小 兵 


public void addSubordinate(Corp corp) { 
this.subordinateList.add(corp); 


} 

// 我 有 哪些 下 属 

public ArrayList<Corp> getSubordinate() { 
return this.subordinateList,; 

} 





场景 类 中 构建 树 形 结构 ， 并 进行 过 历 。 组 厂 没 有 变化 ， 过 有 历 组 织 机 
构 数 稍 有 变化 ， 如 代码 清单 21-17 所 示 。 


代码 清单 21-17 稍稍 修改 的 场景 类 


public class Client { 
// 遍 历 整 棵 树 , 只 要 给 我 根 节点 ， 我 就 能 遍历 出 所 有 的 节点 
public static String getTreeInfo(Branch root){ 
ArrayList<Corp> subordinateList = root.getSubordinat 
String info = ""， 
for(Corp s :subordinateList ){ 
if(s instanceof Leaf){ // 是 员工 就 直接 获得 信 ， 
info = info + S.getInfo()+"Nn"”，; 
}elsef{ // 是 个 小 头目 
info = info+s.getIinfo()+"\n"+ getTreeI 
} 
} 


return info; 























泗 








场景 类 中 main 方 法 没有 变动 ， 请 参考 代码 清单 21-7 所 示 ， 不 再 葡 
裔 历 组 织 机 构 树 的 getTreeInfo 稍 有 修改 ， 就 是 把 用 到 ICorp 接 口 的 地 
方 修改 为 Corp 抽 象 类 ， 其 他 保持 不 变 ， 运 行 结果 相同 。 这 了 吏 是 组 合 模 
二 





21.2 组合 模 闵 的 定义 


组 合 模式 (Composite Pattern) 也 叫 合 成 模式 ， 有 时 又 叫做 部 分 -整体 
模式 (Part-Whole〉 ， 主 要 是 用 来 描述 部 分 与 整体 的 关系 ， 其 定义 如 
下 : 





Compose objects into tree structures to represent part-whole 
hierarchies.Composite lets clients treat individual objects and compositions 
of objects uniformly.〈 将 对 象 组 合成 树 形 结构 以 表示 “部 分 -整体 ”的 层次 
结构 ， 使 得 用 户 对 单个 对 象 和 组 合 对 象 的 使 用 具有 一 致 性 。) 


组 合 模式 的 通用 类 图 ， 如 图 21-6 所 示 。 












Component 
| 
+Operation() 







| 
+Add(Parameterl: Component) 
+Remove(Parameterl1: Component) 


+GetChild(int) 


图 21-6 组 合 模式 通用 类 图 


我 们 先 来 说 说 组 合 模式 的 几 个 角色 。 
e Component 抽 象 构件 角色 


定义 参加 组 合 对 象 的 共有 方法 和 属性 ， 可 以 定义 一 些 默 认 的 行为 或 
属性 ， 比 如 我 们 例子 中 的 getInfo 就 封装 到 了 抽象 类 中 。 


e Leaf 叶 子 构件 
叶子 对 象 ， 其 下 再 也 没有 其 他 的 分 文 ， 也 就 是 过 历 的 最 小 单位 。 
e Composite 树 校 构件 


树 校对 象 ， 它 的 作用 是 组 合 树 校 节 点 和 叶子 节操 形 成 一 个 树 形 结 
构 。 


我 们 来 看 组 合 模式 的 通用 源 人 代码， 首先 看 抽象 构件 ， 它 是 组 合 模式 
的 精 复 ， 如 代码 清单 21-18 所 示 。 


代码 清单 21-18 抽象 构件 


public abstract class Component { 
// 个 体 和 整体 都 具有 的 共享 
public void doSomething(){ 
// 编 写 业 务 逻 辑 
} 


























组 合 模式 的 重点 就 在 树 校 构 件 ， 其 通用 代码 如 代码 清单 21-19 所 


代码 清单 21-19 树枝 构件 


public class Composite extends Component { 
// 构 件 容器 
private ArrayList<Component> componentArrayList = new ArrayL 
// 增 加 一 个 叶子 构件 或 树 校 构件 
public void add(Component component){ 
this.componentArrayList.add(component); 


} 

// 删 除 一 个 叶子 构件 或 树 校 构件 

public void remove(Component component){ 
this.componentArrayList.remove(component); 


} 

// 获 得 分 支 下 的 所 有 叶子 构件 和 树 校 构件 

public ArrayList<Component> getChildren(){ 
return this.componentArrayList; 

} 











树叶 市 点 是 没有 子 下 级 对 象 的 对 象 ， 定 义 参 加 组 合 的 原始 对 象 行 
为 ， 其 通用 源 代码 如 代码 清单 21-20 所 示 。 


代码 清单 21-20 树叶 构件 


public class Leaf extends Component { 
过 

* 可 以 履 写 父 类 方法 

* public void doSomething(){ 


* 


ey 
*/ 





场景 类 负责 树 状 结构 的 建立 ， 并 可 以 通过 递归 方式 遍历 整个 树 ， 如 
代码 清单 21-21 所 示 。 


代码 清单 21-21 场景 类 


public class Client { 
public static void main(String[] args) { 
// 创 建 一 个 根 节点 
Composite root = new Composite(); 
root.doSomething( ); 
// 创 建 一 个 树枝 构件 
Composite branch = new Composite( ); 
// 创 建 一 个 叶子 节点 
Leaf leaf = new Leaf(); 
// 建 立 整体 
root.add(branch ) ; 
branch.add(leaf); 


} 
// 通 过 递归 裔 历 树 
public static void display(Composite root)t{ 
for(Component c:root.getchildren())t{ 
if(c instanceof Leaf){ // 叶 子 节点 
c.doSsomething(); 
}else{ // 树 枝 节 点 
display( (Composite)c); 
} 














各 位 可 能 已 经 看 出 一 些 问题 了 ， 组 合 模式 是 对 依赖 倒转 原则 的 破 
坏 ， 但 是 它 还 有 其 他 关 型 的 变形 ， 面 问 对 象 就 是 这 么 多 的 形态 和 变化 ， 
请 读者 继续 阅读 下 去 ， 惑 会 找到 解决 方案 。 





21.3 组 合 模式 的 应 用 


21.3.1 组 合 模式 的 优点 


高 层 模块 调用 简单 


一 棵 树 形 机 构 中 的 所 有 节点 都 是 Component， 局 部 和 整体 对 调用 者 
来 说 没有 任何 区 别 ， 也 就 是 说 ， 高 层 模 块 不 必 关 心 自己 处 理 的 是 单个 对 
象 还 是 整个 组 合 结构 ， 简 化 了 高 层 模 块 的 代码 。 


e 证 点 目 由 增加 


使 用 了 组 合 模式 后 ， 我 们 可 以 看 看 ， 如 果 想 增加 一 个 树 校 贡 点 、 树 
叶 节 点 是 不 是 都 很 容易 ， 只 要 找到 它 的 父 市 点 束 成 ， 非 第 容易 扩展 ， 符 
合 开 闭 原则 ， 对 以 后 的 维护 非常 有 利 。 








21.3.2 组 合 模式 的 缺点 


组 合 模 式 有 一 个 非 第 明显 的 缺点 ， 看 到 我 们 在 场景 类 中 的 定义 ， 提 
到 树叶 和 树 校 使 用 时 的 定义 了 吗 ? 直接 使 用 了 实现 类 ! 这 在 面向 接口 编 
程 上 是 很 不 恰当 的 ， 与 依赖 倒置 原则 冲突 ， 读 者 在 使 用 的 时 候 要 考虑 清 
楚 ， 它 限制 了 你 接口 的 影响 范围 。 





21.3.3 组 合 模式 的 使 用 场景 


e 维护 和 展示 部 分 -整体 关系 的 场景 ， 如 树 形 菜单 、 文 件 和 文件 夹 管 


e 从 一 个 整体 中 能 够 独立 出 部 分 模块 或 功能 的 场景 。 
21.3.4 组 合 模式 的 注意 事项 
只 要 是 树 形 结构 ， 就 要 考虑 使 用 组 合 模式 ， 这 个 一 定 要 记 住 ， 只 要 


古 要 体现 局 部 和 整体 的 关系 的 时 候 ， 而 且 这 种 关系 还 可 能 比较 深 ， 考 外 
一 下 组 合 模 式 吧 。 


21.4 组 合 模 式 的 扩展 


21.4.1 真实 的 组 合 模 式 





什么 是 真实 的 组 合 模式 ? 就 是 你 在 实际 项 目 中 使 用 的 组 合 模 式 ， 而 
不 是 仅仅 依照 书本 上 学 习 到 的 模式 ， 它 是 “实践 出 真知 ”"。 在 我 们 的 例子 
中 ， 经 过 精简 后 ， 确 实 是 类 、 接 口 减少 了 很 多 ， 而 且 程 序 也 简单 很 多 ， 
但 是 大 家 可 能 还 是 很 迷茫 ， 这 个 Client 程 序 并 没有 改变 多 少 呀 ， 非 常 正 
确 ， 树 的 组 装 是 跑 不 了 的 ， 你 要 知道 在 项 目 中 使 用 关系 型 数据 库 来 存储 
这 些 信息 ， 你 可 以 从 数据 库 中 直接 提取 出 哪些 人 要 分 配 到 树 校 ， 哪 些 人 
要 分 配 到 树叶 ， 树 权 与 树 术 、 树 叶 的 关系 等 ， 这 些 都 是 由 相关 的 业务 人 
员 维 护 到 数据 库 中 的 ， 通 第 这 里 是 把 数据 存放 到 一 张 单独 的 表 中 ， 表 结 
构 如 图 21-7 所 示 。 
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图 21-7 关系 数据 库 中 存储 的 树 形 结构 


这 张 数据 表 定 义 了 一 个 树 形 结 构 ， 我 们 要 做 的 就 是 从 数据 库 中 把 它 
读 取出 来 ， 然 后 展现 到 前 台 上 ， 用 for 循 环 加 上 递归 就 可 以 完成 这 个 读 
取 。 用 了 数据 库 后 ， 数 据 和 逻辑 已 经 在 表 中 定义 好 了 ， 我 们 直接 读 取 放 
到 树 上 就 可 以 了 ， 这 个 还 是 比较 容易 做 的 ， 大 家 不 妨 目 己 考 夸 一 下 。 


这 才 是 组 合 模式 的 真实 引用 ， 它 依靠 了 关系 数据 库 的 非 对 象 存储 性 
能 ， 非 常 方便 地 保存 了 一 个 树 形 结构 。 大 家 可 以 在 项 目 中 考虑 采用 ， 想 
想 看 现在 还 有 哪个 项 目 不 使 用 关系 型 数据 库 呢 ? 


21.4.2 透明 的 组 合 模式 
组 合 模 式 有 两 种 不 同 的 实现 : 透明 模式 和 安全 模式 ， 我 们 上 面 讲 的 


了 怠 是 安全 模式 ， 那 透明 模式 是 什么 样子 呢 ? 透明 模式 的 通用 类 图 ， 如 图 
21-8 所 示 。 


+Operation() 

+Add( Parameterl: Component) 
+Remove(Parameterl: Component) 
+etChild( mt) 





图 21-8 透明 模式 的 通用 类 图 


我 们 与 图 21-6 所 示 的 安全 模式 类 图 对 比 一 下 就 非常 清楚 了 ， 透 明 模 
式 是 把 用 来 组 合 使 用 的 方法 放 到 抽象 类 中 ， 比 如 add0、removeO 以 及 
getChildren 等 方法 (顺便 说 一 下 ，getChildren 一 般 返 回 的 结果 为 Tterable 
的 实现 类 ， 很 多 ， 大 家 可 以 看 JDK 的 帮助 )， 不 管 叶子 对 象 还 是 树枝 对 
象 都 有 相同 的 结构 ， 通 过 判断 是 getChildren 的 返回 值 确认 是 叶子 节点 还 
是 树枝 节点 ， 如 果 处 理 不 当 ， 这 个 会 在 运行 期 出 现 问题 ， 不 是 很 建议 的 
方式 ;安全 模式 就 不 同 了 ， 它 是 把 树枝 节点 和 树叶 节点 彻底 分 开 ， 树 枝 
节点 单独 拥有 用 来 组 合 的 方法 ， 这 种 方法 比较 安全 ， 我 们 的 例子 使 用 了 
安全 模式 


由 于 透明 模式 的 使 用 者 还 是 比较 多 ， 我 们 也 把 它 的 通用 源 代码 共 至 


出 来 ， 首 先 看 抽象 构件 ， 如 代码 清单 21-22 所 示 。 


代码 清单 21-22 抽象 构件 


public abstract class Component { 
// 个 体 和 整体 都 具有 的 共享 
public void doSomething(){ 
// 编 写 业 务 逻 辑 


} 

// 增 加 一 个 叶子 构件 或 树 校 构件 

public abstract void add(Component component); 
// 删 除 一 个 叶子 构件 或 树 校 构件 

public abstract void remove(Component component); 
// 获 得 分 支 下 的 所 有 叶子 构件 和 树 校 构件 


public abstract ArrayList<Component> getChildren( ); 





























抽象 构件 定义 了 树枝 节点 和 树叶 节点 都 必须 具有 的 方法 和 属性 ， 
样 树 校 节 点 的 实现 就 不 需要 任何 变化 ， 如 代码 清单 21-19 所 示 。 








树叶 节点 继承 了 Component 抽 象 类 ， 不 想 让 它 改 变 有 点 难 ， 它 必须 
实现 三 个 抽象 方法 ， 怎 么 办 ? 好 办 ， 给 个 空 方法 ， 如 代码 清单 21-23 所 


钞 。 


代码 清单 21-23 树叶 节点 


public class Leaf extends Component { 
@Deprecated 

public void add(Component component) throws Unsupportedopera 

// 空 实现 , 直接 抛弃 一 个 "不 支持 请 求 "异常 


throw new UnsupportedOperationException(); 











} 
@Deprecated 


public void remove(Component component )throws Unsupportedope 
// 空 实现 
throw new UnsupportedOperationException( ); 


Q@Deprecated 
public ArrayList<Component> getChildren()throws Unsupportedo 


throw new UnsupportedOperationException(); 


为 什么 要 加 个 Deprecated 注 解 呢 ? 就 是 在 编译 器 期 告诉 调用 者 ， 你 
可 以 调 我 这 个 方法 ， 但 是 可 能 出 现 错误 哦 ， 我 已 经 告诉 你 “该 方法 已 经 
失效 ”了 ， 你 还 使 用 那 在 运行 期 也 会 执 出 UnsupportedOperationException 


时 局 于 
开 吓 。 





在 透明 模式 下 ， 遍 历 整 个 树 形 结构 是 比较 容易 的 ， 不 用 进行 强制 类 
型 转换 ， 如 代码 清单 21-24 所 示 。 


代码 清单 21-24 树 结构 遍历 


public class Client { 
// 通 过 递归 裔 历 树 
public static void display(Component root)t{ 
for(Component c:root.getCchildren())t{ 
if(c instanceof Leaf){ // 叶 子 节点 
c.doSsomething(); 
}else{ // 树 枝 节 点 
display(c); 
} 





仅仅 在 过 历时 不 再 进行 牵制 的 类 型 转化 了 ， 其 他 的 组 装 则 没有 任何 
变化 。 透 明 模 式 的 好 处 就 是 它 基 本 遵循 了 依赖 倒转 原则 ， 方 便 系 统 进行 
扩展 。 


21.4.3 组 合 模式 的 遍历 


我 们 在 上 面 也 还 提 到 了 一 个 问题 ， 束 是 树 的 损 历 问题 ， 从 上 到 下 通 
历 没 有 问题 ， 但 是 我 要 是 从 下 往 上 过 历 呢 ? 比如 组 织 机 构 这 棵 树 ， 我 从 
中 抽取 一 个 用 户 ， 要 找到 它 的 上 级 有 哪些 ， 下 级 有 哪些 ， 怎 么 处 理 ? 想 
想 ， 再 想 想 ! 想 出 来 了 吧 ， 我 们 对 下 答案 ， 类 图 如 图 21-9 所 示 。 


+String getInfo() 
#void setParent(Corp corp) 
+Corp getParent() 















图 21-9 增加 父 碍 询 的 类 图 


看 类 图 中 ， 在 Corp 类 中 增加 了 两 个 方法 ，setParent 是 设置 父 节 点 是 
谁 ，getParent 是 但 找 父 节点 是 谁 ， 我 们 来 看 一 下 程序 的 改变 ， 如 代码 清 
单 21-25 所 示 。 


代码 清单 21-25 抽象 构件 


public abstract class Corp { 
// 公 司 每 个 人 都 有 名 称 
private String name = ""， 


// 公 司 每 个 人 都 职位 





private String position = ""; 
// 公 司 每 个 人 都 有 薪水 

private int Salary =0 

// 父 节点 是 谁 
private Corp parent = null; 

public Corp(String _name,String _position,int _salary)t 











this.name = _name; 
this.position = _position; 
this.salary = _salary; 





} 
// 获 得 员工 信息 
public String getInfo(){ 
String info = ""， 
info = "姓名 : " + this,name， 
info = info + "Nt 职位 : "+ this.position; 
info = info + "Nt 薪水 : " + this.salary; 
return info; 











} 

// 设 置 父 节 点 

protected void setParent(Corp _parent ){ 
this.parent = _parent,; 

} 

// 得 到 父 节点 





public Corp getParent(){ 
return this.parent; 
} 


如 代码 清单 21-26 所 示 。 


代码 清单 21-26 树枝 构件 


public class Branch extends Corp { 
// 领 导 下 边 有 哪些 下 级 领导 和 小 兵 
ArrayList<Corp> subordinateList = new ArrayList<Corp>(); 
// 构 造 函 数 是 必需 的 
public Branch(String _name,String _position,int _salary)t{ 
super(_name,_position,_salary); 

















} 

// 增 加 一 个 下 属 ， 可 能 是 小 头目 ， 也 可 能 是 个 小 兵 
public void addSubordinate(Corp corp) { 
corp.setParent(this); // 设 置 父 节点 
this.subordinateList.add(corp); 


} 
// 我 有 哪些 下 属 











public ArrayList<Corp> getSubordinate() { 
return this.subordinateList,; 
} 





走 管 是 树枝 节点 还 是 树叶 节点 ， 在 每 个 节点 都 增加 了 一 个 属性 : 父 
节点 对 象 ， 这 样 在 树枝 节点 增加 子 贡 点 或 叶子 节点 是 设置 父 节 点 ， 然 后 
你 看 整 棵 树 除 了 根 市 点 外 每 个 节点 都 有 一 个 父 贡 点 ， 剩 下 的 事情 还 不 好 
处 理 吗 ? 每 个 节点 上 都 有 父 节 点 了 ， 你 要 往 上 找 ， 那 就 找 员 ! 大 家 目 己 
考虑 一 下 ， 写 个 find 方 法 ， 然 后 一 步 一 步 往 上 找 ， 非 第 简单 的 方法 ， 这 
里 束 不 再 袭 述 。 














有 了 这 个 parent 属 性 ， 什 么 后 序 遇 历 〈 从 下 往 上 找 ) 、 中 序 遇 历 
《从 中 间 某 个 环节 往 上 或 往 下 遍历 ) 都 解决 了 ， 这 个 就 不 多 说 了 。 








再 提 一 个 问题 ， 树 叶 贡 点 和 树 术 节 点 是 有 顺序 的 ， 你 不 能 乱 排 ， 怎 
么 办 ? 比如 我 们 上 面 的 例子 ， 研 发 一 组 下 边 有 3 个 成 员 ， 这 3 个 成 员 要 进 
行 排序 〈 在 机 关 里 这 叫做 排 位 ， 同 样 是 同事 也 有 个 先后 升迁 顺序 ) ， 你 
怎么 处 理 ? 问 我 呀 ， 问 你 呢 ， 好 好 想 想 ， 以 后 用 得 着 的 ! 














21.5 最 佳 实践 





组 合 模 式 在 项 目 中 到 处 都 有 ， 比 如 现在 的 页 面 结构 一 般 都 是 上 下 结 
构 ， 上 面 放 系统 的 Logo， 下 边 分 为 两 部 分 : 左边 是 导航 末 单 ， 右 边 是 展 
示 区 ， 左 边 的 导航 沫 单一 般 痢 是 树 形 的 结构 ， 比 较 清 晰 ， 有 非常 多 的 
JavaScript 源 人 码 实现 了 类 似 的 树 形 菜 单 ， 大 家 可 以 到 网 上 搜索 一 下 。 


还 有 ， 大 家 常用 的 XML 结 构 也 是 一 个 树 形 结构 ， 根 节点 、 元 素 节 
点 、 值 元 素 这 些 都 与 我 们 的 组 合 模式 相 匹 配 ， 之 所 以 本 章节 不 以 XML 
为 例子 讲解 ， 是 因为 很 少 有 人 还 直接 读 写 XML 文 件 ， 一 般 都 是 用 JDOM 
或 者 DOM4J 了 。 











还 有 一 个 非 第 重要 的 例子 : 我 们 自己 本 喘 也 是 一 个 树 状 结构 的 一 个 
树 校 或 树叶 。 根 据 我 能 够 找到 我 的 父母 ， 根 据 父 杀 又 能 找到 和 分 仓 奶奶 ， 
根据 母亲 能 够 找到 外 公 外 婆 等 ， 很 典型 的 树 形 结构 ， 而 且 还 很 规范 这 
个 要 是 不 规范 那 肯 定 乱 套 了 ) 。 


第 22 章 ”观察 者 模式 


22.1 震 非 子 身 按 的 卧 砌 是 谁 派 来 的 


《孙子 兵法 》 有 云 :“ 知 彼 知己 ， 百 战 不 列 :， 不知 彼 而 知己 ， 一 胜 
一 负 ; 不 知 彼 ， 不 知己 ， 每 战 必 列 ”， 那 怎么 才能 知己 知 役 呢 ? 知己 是 
很 容易 的 ， 目 己 的 军队 嘛 ， 很 容易 知 根 知 邱 ， 那 怎么 知 彼 呢 ? 安插 间谍 
征 个 好 办 法 ， 这 是 吾 今 中 外 殿试 不 磷 的 方法 ， 我 们 今天 就 来 讲 一 个 间 恋 
的 故事 。 








韩非子 大 家 都 应 该 记得 吧 ， 法 家 的 代表 人 物 ， 主 张 建 立 法 制 社会 ， 
实施 重 罚 制度 ， 真 是 非常 有 远见 呀 ! 看 看 现在 社会 在 呼吁 什么 ， 建 立法 
制 化 的 社会 ， 这 在 2000 多 年 前 就 已 经 提出 了 。 大 家 可 能 还 不 知道 ， 法 家 
还 有 一 个 非常 重要 的 代表 人 物 一 一 李斯 。 李 斯 是 秦 国 的 承 相 ， 最 终 被 残 
忍 车 裂 的 那 位 ， 李 斯 和 韩非子 都 是 苟 子 的 学 生 ， 李 斯 是 师兄 ， 韩 非 子 是 
师弟 ， 若 干 年 后 ， 李 斯 成 为 最 强 诸侯 国 秦 国 的 上 尉 ， 致 力 于 统一 全 国 ， 
于 是 安插 了 间谍 到 各 个 国家 的 重要 人 物 的 身边 ， 以 获取 必要 的 信息 ， 韩 
非 子 作为 韩国 的 重量 级 人 物 ， 身 边 自然 有 不 少 间谍 ， 韩 非 子 做 的 事 ， 
斯 都 了 如 指 掌 ， 那 可 是 相隔 千里 ! 怎么 做 到 的 呢 ? 间谍 呀 ! 我 们 先 通过 
程序 把 这 个 过 程 展现 一 下 ， 看 看 李斯 是 怎么 监控 韩非子 的 ， 先 看 两 个 主 
角 的 类 图 ， 如 图 22-1 所 示 。 
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图 22-1 监控 者 和 被 监控 者 


仅 有 这 两 个 对 象 还 是 不 够 的 ， 我 们 要 解决 的 是 李斯 是 怎么 监控 韩 非 
子 的 ? 创建 一 个 后 合 线程 一 直 处 于 运行 状态 ， 一 旦 发 现 韩非子 在 吃饭 或 
者 娱乐 就 触发 事件 ? 这 是 真实 世界 的 翻 友 ， 安 排 了 一 个 间 读 ， 观 察 昔 非 
子 的 生活 起 让， 并 上 报 给 李斯 ， 然 后 李斯 再 触发 pdate 事 件 ， 关 疼 继续 
扩充 ， 如 图 22-2 所 示 。 














监控 者 获得 需要 信息 后 的 活动 


<<mnterface>> 
ILiSi 


| | 
+vold update(Strng context) 


<<interface>> 
IHanFeiZi 










+void haveBreakfast() 
+void haveFun() 


LiSi 





-boolean isHavmgBreaktfast Thread 
-boolean isHavingFun 


+getter/setter isHavmgBreakfast() 
+getter/setter isHavmgFun() 
EE 


+vold run() 
图 22-2 通过 后 台 线 程 监控 






















这 个 类 图 应 该 是 程序 员 最 容易 想到 的 ， 你 要 监控 ， 我 就 给 你 找 个 间 
谍 角 色 《〈Spy 类 ) ， 我 们 来 看 程序 的 实现 ， 先 看 我 们 的 主角 韩非子 的 接 
口 〈 类 似 于 韩非子 这 样 的 人 ， 被 观察 者 角色 ) ， 如 代码 清单 22-1 所 示 。 


代码 清单 22-1 被 观察 者 接口 


public interface IHanFeizZi { 
// 韩 非 子 也 是 人 ， 也 要 吃 早饭 的 


public void haveBreakfast( ) ; 











// 畦 非 子 也 是 人 ， 是 人 就 要 娱乐 活动 


public void haveFun(); 





对 接口 进行 扩充 ， 增 加 了 两 个 状态 isHavingBreakfast〈 是 否 在 吃 早 
饭 ) 和 isHavingFun 〈 是 否 在 娱乐 ) ， 以 方便 Spy 进行 监控 ， 如 代码 清单 
22-2 所 示 。 


代码 清单 22-2 具体 的 被 观察 者 


public class HanFeizZi implements IHanFeiZi{ 
// 韩 非 子 是 否 在 吃饭 ， 作 为 监控 的 判断 标准 
private boolean isHavingBreakfast = false; 
// 韩 非 子 是 否 在 娱乐 
private boolean isHavingFun = false; 
// 韩 非 子 要 吃饭 了 
public void haveBreakfast( ){ 
System.out.printLn(" 韩 非 子 : 开 始 吃饭 了 ..."); 


this.isHavingBreakfast =true; 


} 

// 韩 非 子 开始 娱乐 了 

public void haveFun(){ 
System.out.printLn(" 韩 非 子 :开始 娱乐 了 . .."); 
this.isHavingFun = true; 











} 

// 以 下 是 bean 的 基本 方法 ，getter/setter， 不 多 说 

public boolean isHavingBreakfast() { 
return isHavingBreakfast; 





public void setHavingBreakfast(boolean isHavingBreakfast) { 
this.isHavingBreakfast = isHavingBreakfast; 


public boolean isHavingFun() { 
return isHavingFun; 


public void setHavingFun(boolean isHavingFun) { 
this.isHavingFun = isHavingFun; 
} 





其 中 有 两 个 gettersetter 方 法 ， 这 个 就 没有 在 类 图 中 表示 出 来 ， 比 较 


简单 ， 通 过 isHavingBreakfast 和 isHavingFun 这 两 个 布尔 型 变量 来 判断 韩 
非 子 是 否 在 吃饭 或 者 娱乐 ， 韩 非 子 属于 被 观察 者 ， 那 还 有 观察 者 李斯 ， 
我 们 来 看 李斯 的 接口 ， 如 代码 清单 22-3 所 示 。 











代码 清单 22-3 抽象 观察 者 


public interface ILiSi { 
// 一 发 现 别 人 有 动静 ， 自 己 也 要 行动 起 来 


public void update(String context ) 


























李斯 这 类 人 比较 简单 ， 一 发 现 目 己 观察 的 对 象 发 生 了 变化 ， 比 如 吃 
饭 、 娱 乐 ， 目 己 芯 刻 也 要 行动 起 来 ， 怎 么 行动 呢 ? 如 代码 清单 22-4 所 


人 钞 。 





代码 清单 22-4 韩非子 


public class LiSi implements ILiSi{ 
// 首 先 李斯 是 个 观察 者 ， 一 旦 韩非子 有 活动 ， 他 就 知道 ， 他 就 要 向 老板 汇报 
public void update(String str)t{ 
System,out,printlLn(" 李 斯 :观察 到 韩非子 活动 ， 开 始 向 老板 汇报 了 
this.reportToQinShiHuang(str); 
System.out.println(" 李 斯 : 汇报 完毕 ...\n")， 


} 
// 汇 报 给 秦 始 旺 
private void reportToQinShiHuang(String reportContext)t{ 


System.out.println(" 李 斯 : 报告 ， 秦 老板 ! 韩非子 有 活动 了 ---> 













































































两 个 重量 级 的 人 物 痢 定义 出 来 了 ， 间 谍 这 个 “ 插 副 ”小 人 是 不 是 也 要 
登台 了 ， 如 代码 清单 22-5 所 示 。 


代码 清单 22-5 间谍 


class Spy extends Threadt{ 

private HanFeiZi hanFeizi; 

private LiSi 1iSi; 

private String type; 

// 通 过 构造 函数 传递 参数 ， 我 要 监控 的 是 谁 ， 谁 来 监控 ， 要 监控 什么 

public Spy(HanFeiZi _hanFeizi,LiSi _1iSi,String _type)t 
this.hanFeizZi =_hanFeizi; 
this.1iSi = _1iSi; 
this.type = _type; 





























Q@Override 
public void run(){ 
while(true)t 
if(this.type.equals("breakfast")){ // 监 控 是 否 在 吃 
// 如 果 发 现 韩非子 在 吃饭 ， 就 通知 李斯 
if(this.hanFeizi.isHavingBreakfast())t{ 
this.1iSsi.update(" 韩 非 子 在 吃饭 " ) 
// 重 置 状态 ， 继 续 监 控 
this.hanFeizi.setHavingBreakfast(f 
} 
}else{// 监 控 是 否 在 娱乐 
if(this.hanFeizi.isHavingFun())t 
this.1iSi.update(" 辆 非 子 在 娱乐 " ) ; 
this.hanFeiZzi.setHavingFun(false) ; 
} 
} 
} 
} 


监控 程序 继承 了 java.lang.Thread 类 ， 可 以 同时 启动 多 个 线程 进行 监 
控 ，Java 的 多 线程 机 制 还 是 比较 简单 的 ， 继 承 Thread 类 ， 重 写 run() 方 
法 ， 然 后 new SubThread()， 再 然后 subThread.start() 就 可 以 启动 一 个 线程 
了 。 我 们 建立 一 个 场景 类 来 回顾 一 下 这 上段 历史 ， 如 代码 清单 22-6 所 示 。 





代码 清单 22-6 场景 类 


public class Client { 


public static void main(String[] args) throws InterruptedExc 


-一 

















// 定 义 出 韩非子 和 李 基 
LiSi 1iSi = new LiSi(); 

HanFeiZi hanFeizZi = new HanFeizi(); 
// 观 察 早餐 
Watch watchBreakfast = new Watch(hanFeizi,1iSi,"brea 
// 开 始 启 动 线程 ， 监 控 

watchBreakfast.start( ); 

// 观 察 娱乐 情况 

Watch watchFun = new Watch(hanFeizi,1iSi,"fun"); 
watchFun.start(); 

// 然 后 我 们 看 看 韩非子 在 干什么 

Thread,sleep(1000);， // 主 线程 等 待 1 秒 后 后 再 往 下 执行 
hanFeliZi,haveBreakfast() 

// 韩 非 子 娱乐 了 

Thread.sleep(1000); 

hanFeliZi,haveFun( ) ; 











运行 结果 如 下 所 示 : 








韩非子 ， 开始 吃饭 了 .… 





李斯 : 观察 到 韩非子 活动 ， 开 始 向 老板 汇报 了 .… 
































李斯 : 报告 ， 秦 老板 ! 韩非子 有 活动 了 ---> 韩 非 子 在 吃饭 
李斯 : 汇报 完毕 

















韩非子 ， 开始 娱乐 了 .… 





李斯 : 观察 到 韩非子 活动 ， 开 始 向 老板 汇报 了 .… 





李斯 : 


























及 告 ， 秦 老板 ! 娠 非 子 有 活动 了 ---> 震 非 子 在 娱乐 








: 汇报 完毕 


结果 出 来 ， 灾 非 子 一 吃 早 饭 他 斯 残 知 道 ， 理 非 子 一 娱乐 李斯 也 知 
道 ， 非 党 正确 ! 结果 正确 但 并 不 表示 你 有 成 绩 ， 我 告诉 你 : 你 的 成 绩 是 
0， 甚 至 是 负 的 ! 你 有 没有 看 到 你 的 CPU 闫 升 ，Eclipse 不 响应 状态 ? 看 








到 了 ? 看 到 了 你 还 不 想 为 什么 ? ! 看 看 上 面 的 程序 ， 别 的 就 不 多 说 了 ， 
使 用 了 一 个 死 循环 while(true) 来 做 监听 ， 要 是 用 到 项 目 中 ， 你 要 多 少 便 
件 投入 进来 ? 你 还 让 不 让 别人 的 程序 运行 了 ? ! 一 人 台 服 务 器 就 跑 你 这 一 
个 程序 就 完事 ! 





错误 也 看 到 了 ， 我 们 必须 要 修改 ， 这 个 没 法 应 用 到 项 目 中 ， 而 且 这 
个 程序 根本 就 不 是 面向 对 象 的 程序 ， 这 完全 是 面向 过 程 的 ， 不 改 不 行 ， 
怎么 修改 呢 ? 我 们 来 想 ， 既 然 韩 非 子 一 吃饭 李斯 就 知道 了 ， 那 我 们 为 什 
么 不 把 李斯 这 个 类 聚集 到 韩非子 那个 类 上 呢 ? 说 改 就 改 ， 立 马 动手 ， 我 
们 来 看 修改 后 的 类 图 ， 如 图 22-3 所 示 。 











类 图 非常 简单 ， 就 是 在 HanFeiZi 类 中 引用 了 LiSi 实 例 ， 看 我 们 程序 
代码 怎么 修改 ，IHanFeiZi 接 口 完全 没有 修改 ， 可 以 参考 代码 清单 22-1 所 
示 。 我 们 来 看 实现 类 的 修改 ， 如 代码 清单 22-7 所 示 。 

代码 清单 22-7 通过 聚集 方式 的 被 观察 者 


public class HanFeizZi implements IHanFeiZi{ 





























// 把 李斯 声明 出 来 

private ILiSi liSi =new LiSi(); 

// 韩 非 子 要 吃饭 了 

public void haveBreakfast( ){ 
System.out.printLn(" 韩 非 子 : 开 始 吃饭 了 ..."); 
// 通 知 李斯 
this.1iSi.update(" 韩 非 子 在 吃饭 ")，; 

} 

// 韩 非 子 开始 娱乐 了 


public void haveFun()t{ 
System.out,printJlIn(" 韩 非 子 : 开 始 娱乐 了 ,,."); 
this,1iSi,update(" 昔 非 子 在 娱乐 ") ; 




















被 监控 者 吃饭 、 娱 乐 - 监控 者 获得 需要 信息 后 的 活动 


<<interface>> 
ILiSi 


+void update( String context) 


<<interface>> 
Client IHanFeiZi 











+vold haveBreakfast() 
+void haveFun() 


人 


= 


图 22-3 通过 聚集 方式 监控 








韩非子 HanFeiZi 实 现 类 就 把 接口 的 两 个 方法 实现 就 可 以 了 ， 在 每 个 
方法 中 调用 LiSiupdate() 方 法 ， 完 成 李斯 观察 韩非子 的 职责 ， 李 斯 的 接 
口 和 实现 类 都 没有 任何 改变 ， 请 参考 代码 清单 22-3、22-4。 我 们 再 来 看 
看 Client 程 序 的 变更 ， 如 代码 清单 22-8 所 示 。 


代码 清单 22-8 通过 聚集 方式 的 场景 类 


public class Client { 
public static void main(String[|] args) { 
// 定 义 出 畦 非 子 
HanFeiZi hanFeizZi = new HanFeizi(); 
// 然 后 我 们 看 看 韩非子 在 干什么 
hanFeliZi,haveBreakfast() 
// 韩 非 子 娱乐 了 


hanFeliZi,haveFun( ); 








ww 


李斯 束 不 用 在 场景 类 中 定义 了， 非常 简单 ， 运 行 结果 相同 ， 不 再 痪 


BF 








我 们 思考 一 下 ， 修 改 后 的 程序 运行 结果 正确 ， 效 率 也 比较 高 ， 是 不 
古 应 该 乐 呵 乐 呵 了 ? 大 功 告 成 了 ? 稍 等 等 ， 你 想 在 战国 争 雄 的 时 候 ， 吾 
非 子 这 么 有 名 望 、 有 实力 的 人 ， 就 只 有 秦 国 关心 他 吗 ? 想 想 也 不 可 能 
呀 ， 确 实 有 一 大 帮 的 各 国 类 似 于 全 斯 这 样 的 人 在 看 着 他 ， 监 视 关 他 的 一 
举 一 动 ， 但 是 看 看 我 们 的 程序 ， 你 在 HanFeiZi 这 个 类 中 定义 : 





private ILiSi liSi =new LiSi(); 


这 样 一 来 只 有 人 李斯 才能 观察 到 韩非子 ， 这 古 不 对 的 ， 也 束 是 说 韩 非 
子 的 活动 只 通知 了 他 斯 一 个 人 ， 这 不 可 能 ;再 者 说 了， 李斯 只 观察 韩 非 
子 的 吃饭 、 娱 乐 吗 ? 政治 倾向 不 关心 吗 ? 思维 倾向 不 关心 吗 ? 杀 人 放火 
不 天 心 吗 ? 也 就 说 韩非子 的 一 系列 活动 都 要 通知 李斯 ， 这 可 怎么 办 ? 要 
按照 上 面 的 例子 ， 我 们 如 何 修 改 ? 这 和 开 闭 原则 严重 违背 呀 ， 我 们 的 程 
序 有 问题 ， 修 改 如 图 22-4 所 示 。 





被 观察 者 自身 活动 


<<interface>> <<mterface>> i 
i <<interface>> 
IHanFeiZi Observable ] 


Observer 























| 
tvoid haveBreakfast()| | +void addObserver(Observer observer) ER 
+void haveFun() +void deleteObserver(Observer observer) tyromnpuate Gngeontezhl | 


人 +vold notifyObservers(String context) 人 并 人 


\ A 
HanFeiZi 
| 


图 22-4 改进 后 的 观察 者 和 被 观察 者 














LiSi WangSi LiuSi 
































我 们 把 原 有 类 图 做 了 两 个 修改 : 


e@ 增加 Observable 


实现 该 接口 的 都 是 被 观察 者 ， 那 咏 非 子 是 被 观察 者 ， 他 当然 也 要 实 
现 该 接口 了 ， 同 时 他 还 有 与 其 他 良 人 相 异 的 事 要 做 ， 因 此 他 还 是 要 实现 
IHanFeizi 接 口 。 


e 修改 ILiSI 接 口 名 称 为 Observer 





接口 名 称 修改 了 一 下 ， 这 样 显得 更 抽象 化 ， 所 有 实现 该 接口 的 都 是 
观察 者 〈 类 似 李 斯 这 样 的 ) 。 








Observable 是 被 观察 者 ， 就 是 类 似 韩非子 这 样 的 人 ， 在 Observable 接 
口中 有 三 个 比较 重要 的 方法 ， 分 别 是 addObserver 增 加 观察 者 ， 
deleteObserver 删 除 观察 者 ，notifyObservers 通 知 所 有 的 观察 者 ， 这 是 什 

么 意思 呢 ? 我 这 里 有 一 个 信息 ， 一 个 对 象 ， 我 可 以 允许 有 多 个 对 象 来 察 
看 ， 你 观察 也 成 ， 我 观察 也 成 ， 只 要 是 观察 者 就 成 ， 也 就 是 说 我 的 改变 
或 动作 执行 ， 会 通知 其 他 的 对 象 ， 看 程序 会 更 明白 一 点 ， 先 看 
Observable 接 口 ， 如 代码 清单 22-9 所 示 。 








代码 清单 22-9 被 观察 者 接口 


public interface Observable { 
// 增 加 一 个 观察 者 
public void addObserver (Observer observer); 
// 删 除 一 个 观察 者 








public void deleteObserver(Observer observer); 
// 既 然 要 观察 ， 我 发 生 改 变 了 他 也 应 该 有 所 动作 ， 通 知 观察 者 
public void notifyobservers(String context ) 











这 和 古 一 个 通用 的 被 观 峙 者 接口 ， 所 有 的 和 极 观 峙 者 都 可 以 实现 这 个 接 


口 。 再 来 看 韩非子 的 实现 类 ， 如 代码 清单 22-10 所 示 。 


代码 清单 22-10 被 观察 者 实现 类 


public class HanFeliZzi implements Observable ，IHanFelZiL 





// 定 义 个 变 长 数组 ， 存 放 所 有 的 观察 者 
private ArrayList<Observer> observerList = new ArrayList<Obs 
// 增 加 观察 者 
public void addOobserver(Observer observer)t{ 
this.observerList.add(observer); 

















} 

// 删 除 观 察 者 

public void deleteObserver(Observer observer ){ 
this.observerList.remove(observer); 


} 
// 通 知 所 有 的 观察 者 
public void notifyobservers(String context){ 
for(Observer observer:observerList)t{ 
observer .update(context); 
} 


} 

// 韩 非 子 要 吃饭 了 

public void haveBreakfast( ){ 
System.out,printlLn(" 韩 非 子 :开始 吃饭 了 ,.,,"); 
// 通 知 所 有 的 观察 者 
this,notifyobservers(" 韩 非 子 在 吃饭 ") ) 


// 韩 非 子 开始 娱乐 了 

public void haveFun(){ 
System.out.printlLn(" 韩 非 子 : 开 始 娱乐 了 . ..")， 
this,notifyobservers(" 韩 非 子 在 娱乐 ") ， 


























观察 者 只 是 把 原 有 的 ILiSi 接 口 修改 了 一 个 名 字 而 已 ， 如 代码 清单 


22-11 所 示 。 


代码 清单 22-11 观察 者 接口 


public interface Observer { 
// 一 发 现 别 人 有 动静 ， 自 己 也 要 行动 起 来 
public void update(String context); 





























然后 是 三 个 很 无 耻 的 观察 者 ， 咀 先 看 看 真实 的 李斯 ， 如 代码 清单 
22-12 所 示 。 





代码 清单 22-12 具体 的 观察 者 


public class LiSi implements Observert{ 
// 首 先 李 斯 是 个 观察 者 ， 一 旦 韩非子 有 活动 ， 他 就 知道 ， 他 就 要 向 老板 汇报 
public void update(String str)t{ 
System.out.println(" 李 斯 : 观察 到 韩非子 活动 ， 开 始 向 老板 汇报 
this.reportToQinShiHuang(str); 
System.out .printlin(" 李 斯 : 汇报 完毕 ,,,Nn'" ) ， 


} 
// 汇 报 给 秦始皇 
private void reportToQinShiHuang(String reportContext)t{ 


System.out.println(" 李 斯 : 报告 ， 秦 老板 ! 韩非子 有 活动 了 -->" 
} 
















































































李斯 是 真有 其 人 ， 以 下 两 个 观察 者 王 斯 和 刘 斯 是 杜撰 出 来 的 ， 如 代 
码 清 单 22-13 所 示 。 


代码 清单 22-13 杜撰 的 观察 者 


public class WangSi implements Observer{ 
// 王 斯 ， 看 到 韩非子 有 活动 
public void update(String str)t{ 
System.out.println(" 王 斯 :观察 到 韩非子 活动 ， 自 己 也 开始 活动 
this.cry(str); 












































System.out,.printlLn(" 王 斯 ;与 死 了 ...NXn'" ); 


} 
// 一 看 韩非子 有 活动 ， 他 就 痛哭 
private void cry(String context) 

System.out,println(" 王 斯 : 因为 "+context+"，-- 所 以 我 悲伤 
} 


public class LiuSi implements Observert{ 
// 刘 斯 ， 观 察 到 韩非子 活动 后 ， 自 己 也 得 做 一 些 事 
public void update(String str)t{ 
System.out.println(" 刘 斯 :观察 到 韩非子 活动 ， 开 始 动 作 了 ..." 
this.happy(str); 
System,out .println(" 刘 斯 :， 乐 死 了 \n"); 


} 
// 一 看 韩非子 有 变化 ， 他 就 快乐 
private void happy(String context)t{ 
System,out.printlLn(" 刘 斯 ; 因为 " tcontext+", -- 所 以 我 快乐 
} 
















































































所 有 的 历史 人 物 痢 在场 了 ， 那 我 们 来 看 看 这 场 历 史 闸 剧 是 如 何 演绎 
的 ， 如 代码 清单 22-14 所 示 。 


代码 清单 22-14 场景 类 


public class Client { 
public static void main(String[] args) { 

// 三 个 观察 者 产生 出 来 
Observer 1iSi = new LiSi(); 
Observer wangSi = new WangSi(); 
Observer liuSi = new LiuSi(); 
// 定 义 出 韩非子 
HanFeiZi hanFeizZi = new HanFeizi(); 
// 我 们 后 人 根据 历史 ， 描 述 这 个 场景 ， 有 三 个 人 在 观察 韩非子 
hanFeiZi.addObserver(1iSi); 
hanFeiZi.addObserver (wangSi); 
hanFeizZi.addOobserver(1iuSsi); 
// 然 后 这 里 我 们 看 看 韩非子 在 干什么 


hanFeliZi,haveBreakfast() 





























运行 结果 如 下 所 示 : 





韩非子 ， 开始 吃饭 了 .… 











李斯 : 观察 到 韩非子 活动 ， 开 始 向 老板 汇报 了 .… 








李斯 : 报告 ， 秦 老板 ! 韩非子 有 活动 了 -> 韩非子 在 吃饭 




















李斯 : 汇报 完毕 .… 

















王 斯 : 观察 到 韩非子 活动 ， 自 己 也 开始 活动 了 .… 








王 斯 : 因为 韩非子 在 吃饭 一 一 所 以 我 悲伤 呀 ! 














刘 斯 : 观察 到 韩非子 活动 ， 开 始 动作 了 .… 


























刘 斯 : 因为 韩非子 在 吃饭 一 一 所 以 我 快乐 蚜 ! 








好 了 ， 结 果 也 正确 了 ， 也 符合 开 闭 原则 了 ， 同 时 也 实现 类 间 解 耦 ， 
想 再 加 观察 者 ? 继续 实现 Observer 接口 束 成 了 ， 这 时 候 必须 修改 Client 程 
序 ， 因 为 你 的 业务 都 发 生 了 变化 。 这 束 是 观察 者 模式 。 


22.2 观察 者 模式 的 定义 


观察 者 模式 (Observer Pattern〉 也 叫做 发 布 订阅 模式 
(Publish/subscribe) , 它 是 一 个 在 项 目 中 经 各 使 用 的 模式 ， 其 定义 如 
下 : 


Define a one-to-many dependency between objects so that when one 
object changes state,all its dependents are notified and updated automatically. 
(定义 对 象 间 一 种 一 对 多 的 依赖 关系 ， 使 得 每 当 一 个 对 象 改 变 状态 ， 则 
所 有 依赖 于 它 的 对 象 部 会 得 到 通知 并 被 自动 更 新 。) 





观察 者 模式 的 通用 类 图 ， 如 图 22-5 所 示 。 






十 Subject 





+Attach(o: ObserverT) 
+Detach(o: Observer) 
+Notiy() 






+Update() 






ConcreteSubject ConcreteObserver 


图 22-5 观察 者 模式 通用 类 图 


我 们 先 来 解释 一 下 观察 者 模式 的 几 个 角色 名 称 : 
e Subject 被 观察 者 


定义 被 观察 者 必须 实现 的 职责 ， 它 必须 能 够 动态 地 增加 、 取 消 观 察 
者 。 它 一 般 是 抽象 类 或 者 是 实现 类 ， 仅 仅 完成 作为 被 观察 者 必须 实现 的 
职 贡 : 管理 观察 者 并 通知 观察 者 。 





e@ Observer 观 察 者 


观察 者 接收 到 消息 后 ， 即 进行 Update 更 新 方法 ) 操作 ， 对 接收 到 
的 信息 进行 处 理 。 


e ConcreteSubject 有 具体 的 被 观察 者 
定义 被 观察 者 自己 的 业务 逻辑 ， 同 时 定义 对 哪些 事件 进行 通知 。 


e@ ConcreteObserver 具 体 的 观察 者 








每 个 观察 在 接收 到 消息 后 的 处 理 反 应 是 不 同 ， 各 个 观察 者 有 目 己 的 
处 理 逻 辑 。 


各 个 名 词 介绍 完毕 ， 我 们 来 看 看 各 目的 通用 代码 ， 先 看 被 观察 者 角 
色 ， 如 代码 清单 22-15 所 示 。 


代码 清单 22-15 被 观察 者 


public abstract class Subject { 
// 定 义 一 个 观察 者 数组 
private Vector<Observer> obsVector = new Vector<Observer>(); 
// 增 加 一 个 观察 者 
public void addObserver(Observer 0){ 
this.obsVector.add(o); 











} 

// 删 除 一 个 观察 者 

public void delObserver(Observer 0){ 
this.obsVector.remove(o); 


} 
// 通 知 所 有 观察 者 
public void notifyobservers(){ 
for(Observer o:this.obsVector)t{ 
o.update( ); 
} 











被 观察 者 的 职员 非常 简单 ， 就 是 定义 谁 能 够 观察 ， 谁 不 能 观察 ， 程 
序 中 使 用 ArrayList 和 Vector 没有 太 大 的 差别 ，ArrayList 是 线程 异步 ， 不 





安全 ;Vector 是 线程 同步 ， 安 全 一 一 就 这 点 区 别 。 我 们 再 来 看 具体 的 被 


观察 者 ， 如 代码 清单 22-16 所 示 。 


代码 清单 22-16 具体 被 观察 者 


public class ConcreteSubject extends Subject { 
// 有 具体 的 业务 
public void doSomething(){ 
pi 
* do something 


super .notifyObservers( ); 








我 们 现在 看 到 的 是 一 个 纯净 的 观察 者 ， 在 具体 项 目 中 该 类 有 很 多 的 
变种 ， 在 22.4 一 节 中 介绍 。 


我 们 再 来 看 观察 者 角色 ， 如 代码 清单 22-17 所 示 。 


代码 清单 22-17 观察 者 


public interface Observer { 
// 更 新 方法 
public void update( ); 








观察 者 一 般 是 一 个 接口 ， 每 一 个 实现 该 接口 的 实现 类 都 是 具体 观察 
者 ， 如 代码 清单 22-18 所 示 。 
代码 清单 22-18 具体 观察 者 


public class ConcreteObserver implements Observer { 
// 实 现 更 新 方法 





public void update() { 
System.out,.printlLn(" 接 收 到 信息 ， 并 进行 处 理 ! ")， 
} 























其 他 模块 是 怎么 来 调用 的 呢 ? 我 们 编写 一 个 Client 关 来 描述 ， 如 
代码 清单 22-19 所 示 。 


代码 清单 22-19 场景 类 


public class Client { 

public static void main(String[] args) { 
// 创 建 一 个 被 观察 者 
ConcreteSubject subject = new ConcreteSubject( ) ， 
// 定 义 一 个 观察 者 
Observer obs= new ConcreteObserver(); 
// 观 察 者 观 迷人 缚 人 有 被 观察 者 
Subject .addobserver(obs ) ; 
// 观 察 者 开始 活动 了 
Subject .doSomething() ; 


























22.3 观察 者 模式 的 应 用 


22.3.1 观察 者 模式 的 优点 


观察 者 和 被 观察 者 之 间 是 抽象 耘 合 





如 此 设计 ， 则 不 管 是 增加 观察 者 还 是 被 观察 者 都 非常 容易 扩展 ， 而 
且 在 Java 中 都 已 经 实现 的 抽象 层级 的 定义 ， 在 系统 扩展 方面 更 是 得 心 应 
Ee 








e 建立 一 僚 触 发 机 制 


根据 单一 职责 原则 ， 每 个 类 的 职责 是 单一 的 ， 那 么 怎么 把 各 个 单一 
的 职 贡 串联 成 真实 世界 的 复杂 的 逻辑 关系 呢 ?” 比 如 ， 我 们 去 打猎 ， 打 死 
了 一 只 母 庆 ， 母 让 有 三 个 幼 患 ， 因 失去 了 母 鹿 而 饿 死 ， 尸 体 又 被 两 只 葛 
鹰 争 抢 ， 因 分 配 不 均 ， 秃 座 开 始 斗山 ， 然 后 说 弱 的 秃 订 死 近 ， 和 生存 下 来 
的 秃 麻 ， 则 因此 扩大 了 地 盘 .…… 这 就 是 一 个 触发 机制， 形成 了 一 个 触发 
链 。 观 察 者 模式 可 以 完 关 地 实现 这 里 的 链条 形式 。 





22.3.2 观察 者 模式 的 缺点 





观察 者 模式 需要 考虑 一 下 开发 效率 和 运行 效率 问题 ， 一 个 被 观察 





者 ， 多 个 观察 者 ， 开 发 和 调试 就 会 比较 复杂 ， 而 且 在 Java 中 消息 的 通知 
默认 是 顺序 执行 ， 一 个 观察 者 卡 壳 ， 会 影响 整体 的 执行 效率 。 在 这 种 情 
况 下 ,一般 考虑 采用 异步 的 方式 。 





多 级 触发 时 的 效率 更 是 让 人 担忧 ， 大 家 在 设计 时 注意 考虑 。 


22.3.3 观察 者 模式 的 使 用 场景 





e 关联 行为 场景 。 需 要 注意 的 是 ， 关 联 行为 是 可 拆 分 的 ， 而 不 
是 “组 合 ” 关 系 , 


e 事件 多 级 触发 场景 。 


e 跨 系 统 的 消息 交换 场景 ， 如 消息 队列 的 处 理 机 制 |。 
22.3.4 观察 者 模式 的 注意 事项 


使 用 观察 者 模式 也 有 以 下 两 个 重点 问题 要 解决 。 
e 广播 链 的 问题 


如 果 你 做 过 数据 库 的 触发 器 ， 你 惑 应 该 知道 有 一 个 触发 器 链 的 问 
题 ， 比 如 表 A 上 写 了 一 个 触 肥 器， 内 容 是 一 个 字段 更 新 后 更 新 表 B 的 一 
条 数据 ， 而 表 B 上 也 有 个 触发 器 ， 要 更 新 表 C， 表 C 也 有 触发 需 .……… 完 重 











了 ， 这 个 数据 库 基 本 上 惑 毁 反 了 ! 我 们 的 观察 者 模式 也 是 一 样 的 问题 ， 
一 个 观察 者 可 以 有 双重 身份 ， 既 是 观察 者 ， 也 是 被 观察 者 ， 这 没什么 问 
题 呀 ， 但 是 链 一 旦 建立 ， 这 个 过 辑 束 比较 复杂 ， 可 维护 性 非常 差 ， 根 据 
经 验 建 议 ， 在 一 个 观察 者 模式 中 最 多 出 现 一 个 对 象 既 是 观察 者 也 是 家 观 
察 者 ， 也 就 是 说 消息 最 多 转发 一 次 《传递 两 次 ) ， 这 还 是 比较 好 控制 

的 。 




















注意 ” 它 和 责任 链 模式 的 最 大 区 别 就 是 观察 者 广播 链 在 传播 的 过 
程 中 消 妃 是 随时 更 改 的 ， 它 是 由 相 邻 的 两 个 节点 协商 的 消 妃 结构 ， 而 责 
任 链 模式 在 消息 传递 过 程 中 基本 上 保持 消息 不 可 变 ， 如 果 要 改变 ， 也 只 
征 在 原 有 的 消 妃 上 进行 修正 。 





e 异步 处 理 问题 





这 个 EJB 是 一 个 非常 好 的 例子 ， 被 观察 者 发 生动 作 了 ， 观 察 者 要 做 
出 回应 ， 如 果 观 察 者 比较 多 ， 而 且 处 理 时 间 比 较 长 怎么 办 ?” 那 就 用 异步 
呐 ， 异 步 处 理 就 要 考虑 线程 安全 和 队列 的 问题 ， 这 个 大 家 有 时 间 看 看 
Message Queue， 就 会 有 更 深 的 了 解 。 





22.4 观察 者 模式 的 扩展 


22.4.1 Java 世 界 中 的 观察 者 模式 








细心 的 你 可 能 已 经 发 现 ，HanFeiZi 这 个 实现 类 中 应 该 抽象 出 一 个 父 
类 ， 父 类 完全 作为 被 观察 者 的 职责 ， 每 一 个 被 观察 者 只 实现 自己 的 多 辑 
方法 融 可 以 了 ， 如 此 则 非常 符合 单一 职责 原则 。 是 的 ， 确 实 是 应 该 这 
样 。 幸 运 的 是 ，Java 从 一 开始 诞生 就 提供 了 一 个 可 扩展 的 父 类 ， 即 
java.util.Observable， 这 个 类 了 吏 是 为 那些 “ 骏 露 狂 ?”i 准 备 的 ， 他 们 老 是 喜欢 
把 自己 的 状态 变更 让 别人 去 欣赏 ， 去 触发 ， 这 正 符 合 了 我 们 现在 的 要 
求 ， 要 把 韩非子 的 所 有 活动 都 暴露 出 去 ， 并 且 想 驼 露 给 谁 承 暴 露 给 谁 。 
我 们 打开 Java 的 帮助 文件 看 看 ， 查 找 一 下 Observable 是 不 是 已 经 有 这 个 
类 了 ?JDK 中 提供 了 :java.util.Observable 实 现 类 和 java.util.Observer 接 
口 ， 也 就 是 说 我 们 上 面 写 的 那个 例子 中 的 Observable 接 口 可 以 改换 成 
java.util.Observale 实 现 类 了 ， 如 图 22-6 所 示 。 


<<interface>> 
java.util.Observer 
大 +void update(String context)() 
+void haveFun() 六 碎 A 




























<<interface>> 


IHanFeiZi java.util.Observable 


| EE 一 
+void haveBreakfast() 一 一 一 

















ECC | 











图 22-6 Java 中 的 观察 者 类 图 


是 不 是 又 简单 了 很 多 ? 那 就 对 了 ! 然后 我 们 看 一 下 我 们 程序 的 变 
更 ， 先 看 HanFeiZi 的 实现 类 ， 如 代码 清单 22-20 所 示 。 


代码 清单 22-20 优化 后 的 被 观察 者 


public class HanFeiZi extends Observable,IHanFeiZif{ 
// 圩 非 子 要 吃饭 了 
public void haveBreakfast(){ 
System.out.println(" 韩 非 子 : 开始 吃饭 了 ...")， 
// 通 知 所 有 的 观察 者 
Super ,SetCchanged() ， 
super ,notifyobservers(" 韩 非 子 在 吃饭 ") ; 


} 

// 畦 非 子 开始 娱乐 了 

public void haveFun(){ 
System.out.println(" 韩 非 子 : 开始 娱乐 了 ...")，; 
Super ,SetChanged() ， 
this,notifyobservers(" 韩 非 子 在 娱乐 ") ， 











改变 得 不 多 ， 引 入 了 一 个 java.util.Observable 对 象 ， 删 除了 增加 、 删 
除 观 察 者 的 方法 ， 简 单 了 很 多 ， 那 我 们 再 来 看 观察 者 的 实现 类 ， 如 代码 
清单 22-21 所 示 。 


代码 清单 22-21 优化 后 的 观察 者 


public class LiSi implements Observert{ 
// 首 先 李斯 是 个 观察 者 ， 一 旦 韩非子 有 活动 ， 他 就 知道 ， 他 就 要 向 老板 汇报 
public void update(Observable observable,oObject obj ){ 
System.out.println(" 李 斯 : 观察 到 韩非子 活动 ， 开 始 向 老板 汇 
this.reportToQinShiHuang(obj. ed 0s 
System.out.println(" 李 斯 : 汇报 完毕 ...\n"); 


} 
// 汇 报 给 秦 始 旦 









































CE 
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private void reportToQinShiHuang(String reportContext)t{ 


System.out .println(" 李 斯 : 报告 ， 秦 老板 ! 韩非子 有 活动 了 ---> 
} 

















应 java.util.Observer 接 口 要 求 update 传 递 过 来 两 个 变量 ，Observable 
这 个 变量 我 们 没 用 到 (接口 中 定义 必须 实现 的 ) ， 就 不 处 理 了 。 其 他 两 
个 观察 者 实现 类 也 是 相同 的 改动 ， 不 再 资 述 











场景 类 没有 改动 ， 运 行 结果 也 完全 相同 ， 大 家 看 看 我 们 使 用 了 Java 
提供 的 观察 者 模式 后 是 不 是 简单 了 很 多 ， 所 以 在 Java 的 世界 里 横行 时 ， 
多 看 看 API， 有 帮助 很 大 ， 很 多 东西 Java 已 经 帮 你 设计 了 一 个 民 好 的 框 


口 
架 。 











22.4.2 项 目 中 真实 的 观察 者 模式 


为 什么 要 说 “真实 " 呢 ? 因 为 我 们 刚刚 讲 的 那些 是 太 标 准 的 模式 了 ， 
在 系统 设计 中 会 对 观察 者 模式 进行 改造 或 改装 ， 主 要 在 以 下 3 个 方面 。 





e 观察 者 和 被 观 岁 者 之 间 的 消 奶 沟通 


被 观察 者 状态 改变 会 触发 观察 者 的 一 个 行为 ， 同 时 会 传递 一 个 消息 
给 观察 者 ， 这 是 正确 的 ， 在 实际 中 一 般 的 做 法 是 ， 观察 者 中 的 update 方 
法 接受 两 个 参数 ， 一 个 是 被 观察 者 ， 一 个 是 DTO (Data Transfer 
Object， 据 传输 对 象 )，DTO 一 般 是 一 个 纯洁 的 JavaBean, 由 被 观察 者 生 
成 ， 由 观察 者 消费 。 


当然 ， 如 果 考 碟 到 远程 传输 ， 一 般 消 息 是 以 XML 格式 传递 。 


e 观察 者 啊 应 方式 


我 们 这 样 来 想 一 个 问题 ， 观 察 者 是 一 个 比较 复杂 的 逻辑 ， 它 要 接受 
被 观察 者 传递 过 来 的 信息 ， 同 时 还 要 对 他 们 进行 逻辑 处 理 ， 在 一 个 观察 
者 多 个 被 观察 者 的 情况 下 ， 性 能 束 需 要 提 到 日 程 上 来 考虑 了 ， 为 什么 
呢 ? 如 果 观 察 者 来 不 及 啊 应 ， 被 观 岁 者 的 执行 时 间 是 不 是 也 会 被 拉 长 ? 
那 现 在 的 问题 就 是 : 观察 者 如 何 快速 啊 应 ? 有 两 个 办 法 : 一 是 采用 多 线 
程 技术 ， 表 管 是 被 观察 者 启动 线程 还 是 观察 者 启动 线程 ， 都 可 以 明显 地 
提高 系统 性 能 ， 这 也 就 是 大 家 通常 所 说 的 异步 染 构 ， 二 是 绥 存 技术 ， 朋 
管 你 谁 来 ， 我 已 经 准备 了 足够 的 资源 给 你 了 ， 我 保证 快速 啊 应 ， 这 当然 
也 是 一 种 比较 好 方案 ， 代 价 就 是 开发 难度 很 大 ， 而 且 压 力 测试 要 做 的 足 
够 充分 ， 这 种 方案 也 束 是 大 家 说 的 同步 架构 。 























e 被 观 罕 者 尽量 自己 做 主 





这 是 什么 意思 呢 ? 被 观察 者 的 状态 改变 是 否 一 定 要 通知 观察 者 呢 ? 
不 一 定 吧 ， 在 设计 的 时 候 要 灵活 考虑 ， 否 则 会 加 重 观察 者 的 处 理 罗 辑 ， 
一 般 是 这 样 做 的 ， 对 被 观察 者 的 业务 逻辑 doSomething 方 法 实现 重 载 ， 
如 增加 一 个 doSomething(boolean isNotifyObs) 方 法 ， 决 定 是 否 通知 观察 
者 ， 而 不 是 在 消息 到 达观 察 者 时 才 判 断 是 人 否 要 消费 。 





22.4.3 订阅 发 布 模型 


观察 者 模式 也 叫做 发 布 /订阅 模型 (Publish/Subscribe) ， 如 果 你 做 
过 EJB 〈Enterprise JavaBean) 的 开发 ， 这 个 你 绝对 不 会 陌生 。EJB2 是 个 
折腾 死人 不 偿命 的 玩意 儿 ， 写 个 Bean 要 实现 ， 还 要 继承 ， 再 加 上 那 一 堆 
的 配置 文件 ， 小 项 目 还 凑合 ， 你 要 知道 用 EJB 开 发 的 基本 上 都 不 是 小 项 
目 ， 到 最 后 是 每 个 项 目 成 员 都 在 吕 EJB 这 个 忽悠 人 的 东西 ， 但 是 EJB3 是 
个 非常 优秀 的 框架 ， 还 是 算 比 较 轻 量 级 ， 写 个 Bean 只 要 加 个 Annotaion 
就 成 了 ， 配 置 文件 减少 了 ， 而 且 也 引入 了 依赖 注入 的 概念 ， 虽 然 只 是 
EJB2 的 翻版 ， 但 是 毕竟 还 是 前 进 了 一 步 。 在 EJB 中 有 3 个 类 型 的 Bean: 


Session Bean、Entity Bean 和 MessageDriven Bean， 我 们 这 里 来 说 一 下 

















MessageDriven Bean (一般 简称 为 MDB) ， 消 息 驱 动 Bean， 消 息 的 发 布 
者 (Provider) 发 布 一 个 消 筷 ， 也 就 是 一 个 消息 驱动 Bean， 通 过 EJB 容 器 
(一 般 是 Message Queue 消 息 队 列 ) 通知 订阅 者 做 出 回应 ， 从 原理 上 看 
很 简单 ， 就 是 观察 者 模式 的 升级 版 ， 或 者 说 是 观察 则 模式 的 BOSS 版 。 








22.5 最 佳 实践 





观察 者 模式 在 实际 项 目 和 生活 中 非常 常见 ， 我 们 举 几 个 经 党 发 生 的 
例子 来 说 明 。 


e 文件 系统 





比如 ， 在 一 个 目录 下 新 建立 一 个 文件 ， 这 个 动作 会 同时 通知 目录 管 
理 咽 增加 该 目录 ， 并 通知 磁盘 管理 喜 减 少 1KB 的 空间 ， 也 就 说 “文件 ”是 
一 个 被 观察 者 , “目录 管理 器 ?和 “位 盘 管 理 器 ? 则 是 观察 者 。 





e 狂 鼠 游戏 


夜里 猎 叫 一 声 ， 家 里 的 老鼠 撒 腿 就 跑 ， 同 时 也 吵 醒 了 熟睡 的 主人 ， 
这 个 场景 中 ,，“ 独 ”就 是 被 观察 者 ， 老 鼠 和 人 则 是 观察 者 。 


e ATM 取 钱 


比如 你 到 ATM 机 右上 取 钱 ， 多 次 输 错 密码 ， 卡 就 会 梓 ATM 香 邱 ， 
香 卡 动作 发 生 的 时 候 ， 会 触发 哪些 事件 呢 ? 第 一 ， 摄 像 头 连 续 快 拍 ， 第 
二 ， 通 知 监控 系统 ， 香 卡 发 生 ， 第 三 ， 初 始 化 ATM 机 屏幕 ， 返 回 最 初 
状态 。 一 般 前 两 个 动作 都 是 通过 观察 者 模式 来 完成 的 ， 后 一 个 动作 是 异 
常 来 完成 。 


e 广播 收音 机 


电台 在 广播 ， 你 可 以 打开 一 个 收音 机 ， 或 者 两 个 收音 机 来 收听 ， 电 
台 吕 是 被 观察 者 ， 收 音 机 就 是 观察 者 。 


第 23 草 ”门面 模式 


23.1 我 要 投递 信件 


我 们 都 写 过 纸 质 信件 吧 ， 比 如 给 女 朋 友 写 情书 什么 的 。 写 信 的 过 程 
大 家 应 该 都 还 记得 一 一 先 写 信 的 内 容 ， 然 后 写 信封 ， 再 把 信 放 到 信封 
中 ， 封 好 ， 投 递 到 信箱 中 进行 邮递 ， 这 个 过 程 还 是 比较 简单 的 ， 虽 然 简 
单 ， 但 是 这 4 个 步骤 都 不 可 或 缺 ! 我 们 先 把 这 个 过 程 通过 程序 实现 出 
来 ， 如 图 23-1 所 示 。 


ER 
三 信和 的 过 程 


<<interface>> 
ILetterProcess 


+Vold writeContext(Strmg context) 


| 

| +void fllEnvelope(String address) 
Hvoid letterInotoEnvelope() 
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LetterProcessImpl 
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写 信 过 程 的 具体 实现 






图 23-1 写 信 过 程 类 图 


这 一 个 过 程 还 是 比较 简单 的 ， 我 们 看 程序 的 实现 ， 先 看 接口 ， 如 代 
码 清单 23-1 所 示 。 


代码 清单 23-1 写 信 过 程 接口 


public interface ILetterProcess { 
// 首 先 要 写 信 的 内 容 
public void writecontext(String context ) ; 
// 其 次 写 信封 





public void fillEnvelope(String address ) ; 
// 把 信 放 到 信封 里 

public void letterIinotoEnvelope( ) ; 

// 然 后 邮递 

public void sendLetter(); 








在 接口 中 定义 了 完成 的 一 个 写 信 过 程 ， 这 个 过 程 需要 实现 ， 其 实 丽 
类 如 代码 清单 23-2 所 示 。 


代码 清单 23-2 写 信 过 程 的 实现 


public class LetterProcessIimpl implements ILetterProcess { 

// 写 信 
public void writeContext(String context) { 

System.out.,println(" 填 写 信 的 内 容 ,.." + context); 


} 

// 在 信封 上 填写 必要 的 信息 

public void fillEnvelope(String address) { 
System.out.println(" 填 写 收 件 人 地 址 及 姓名 ,..," + address)， 


} 

// 把 信 放 到 信封 中 ， 并 封 好 

public void letterInotoEnvelope() { 
System.out.println(" 把 信 放 到 信封 中 ..."); 


} 
// 塞 到 邮箱 中 ， 邮 递 
public void sendLetter() { 
System.out ,println(" 邮 递 信 件 .,..")， 


























在 这 种 环境 下 ， 最 味 的 是 写 信 人 ， 为 了 发 送 一 封 信 要 有 4 个 步骤， 
而 且 这 4 个 步骤 还 不 能 颠倒 ， 我 们 移 看 看 这 个 过 程 如 何 通 过 程序 表现 出 
来 ， 有 人 开始 用 这 个 过 程 写 信 了 ， 如 代码 清单 23-3 所 示 。 











代码 清单 23-3 场景 类 


public class Client { 


public static void main(String[] args) { 
// 创 建 一 个 处 理 信 件 的 过 程 
ILetterProcess letterProcess = new LetterProcessImpl 
// 开 始 写 信 
letterProcess.writeContext("Hello,It's me,do you kno 
// 开 始 写 信封 
letterProcess.fillEnvelope("Happy Road No. 666,God P 
// 把 信 放 到 信封 里 ， 并 封装 好 
letterProcess.1letterIinotoEnvelope( ); 
// 跑 到 邮局 把 信 塞 到 邮箱 ， 投 递 
letterProcess.sendLetter(); 


























-一 


运行 结果 如 下 所 示 : 
填写 信 的 内 容 ...Hello,It's me,do you know who I am? Im your old lover. Pd like to... 


填写 收 件 人 地 址 及 姓名 ...Happy Road No. 666,God Province,Heaven 





把 信 放 到 信封 中 .… 


邮递 信件 .… 





我 们 回 过 头 来 看 看 这 个 过 程 ， 它 与 高 内 聚 的 要 求 相 差 其 远 ， 更 不 要 
说 迪 米 特 法 则 、 接 口 隔 离 原 则 了 。 你 想 想 ， 你 要 知道 这 4 个 步 又， 而 且 
还 要 知道 它们 的 顺序 ， 一 旦 出 错 ， 信 就 不 可 能 邮寄 出 去 ， 这 在 面向 对 象 
的 编程 中 是 极度 地 不 适合 ， 它 根本 就 没有 完成 一 个 类 所 具有 的 单一 职 











潍 





还 有 ， 如 采信 件 多 了 就 非常 咏 烦 ， 每 封 信 都 要 这 样 运转 一 过 ， 非 得 
索 死 ， 更 别 说 要 发 个 广告 信 了 ， 那 怎么 办 昵 ? 还 好 ， 现 在 邮局 开发 了 一 
个 新 业务 ， 你 只 要 把 信件 的 必要 信息 告诉 我 ， 我 给 你 发 ， 我 来 完成 这 4 
个 过 程 ， 只 要 把 信件 交 给 我 就 成 了 ， 其 他 束 不 要 管 了 。 非 党 好 的 方 双 





我 们 来 看 类 图 ， 如 图 23-2 所 示 。 
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+Void writeContext(String context) -ILetterProcess letterProcess 


+void fillEnvelope(Strmg address) 
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写 信 过 程 的 具体 实现 





图 23-2 增加 现代 化 邮局 的 类 图 





这 还 是 比较 简单 的 类 图 ， 增 加 了 一 个 ModenPostOffice 类 ， 负 责 对 一 
个 比较 复杂 的 信件 处 理 过 程 的 封装 ， 然 后 高 层 模块 只 要 和 它 有 交互 就 成 
了 ， 如 代码 清单 23-4 所 示 。 








代码 清单 23-4 现代 化 邮局 


public class ModenPostOffice { 
private ILetterProcess letterProcess = new LetterProcessImpl 
// 写 信 ， 封 装 ， 投 递 ， 一 体 化 
public void sendLetter(String context,String address)t{ 
// 帮 你 写 信 
letterProcess.writeContext(context); 
// 写 好 信封 


letterProcess.fillEnvelope(address); 
// 把 信 放 到 信 封 中 
letterProcess.1letterIinotoEnvelope(); 
// 邮 递 信件 


letterProcess.sendLetter(); 








这 个 类 是 什么 意思 呢 ， 融 是 说 现在 有 一 个 Hell Road PostOffice( 地 
狱 路 邮局 ) 提供 了 一 种 新 型 服务 ， 客 户 只 要 把 信 的 内 容 以 及 收 信 地 址 给 
他 们 ， 他 们 就 会 把 信 写 好 ， 封 好 ， 并 发 送出 去 。 这 种 服务 推出 后 大 受 欢 
迎 ， 这 多 简单 ， 客 户 减 少 了 很 多 工作 ， 谁 不 乐意 呀 。 那 我 们 看 看 客户 是 
怎么 调用 的 ， 如 代码 清单 23-5 所 示 。 





代码 清单 23-5 场景 类 


public class Client { 
public static void main(String[] args) { 

// 现 代 化 的 邮局 ， 有 这 项 服务 ， 邮 局 名 称 叫 Hell Road 
ModenPostoffice hellRoadPostOffice = new ModenPostof 
// 你 只 要 把 信和 的 内 容 和 收 信人 地 址 给 他 ， 他 会 帮 你 完成 一 系列 的 工作 
// 定 义 一 个 地 址 
String address = "Happy Road No. 666,God Province,He 
// 信 的 内 容 
String context = "Hello,It's me,do you know who I am 
// 你 给 我 发 送 吧 
hellRoadPostOoffice.sendLetter(context, address); 


























了 结果 是 相同 的 。 我 们 看 看 场景 类 是 不 是 简化 了 很 多 ， 只 要 与 
ModenPostOffice 交 互 就 成 了 ， 其 他 的 什么 都 不 用 管 ， 写 信封 啦 、 写 地 址 
啦 .……. 都 不 用 关心 ， 只 要 把 需要 的 信息 提交 过 去 就 成 了 ， 邮 局 保证 会 按 
照 我 们 指定 的 地 址 把 指定 的 内 容 发 送出 去 ， 这 种 方式 不 仅 简单 ， 而 且 扩 








展 性 还 非常 好 ， 比 如 一 个 非常 时 期 ， 寄 往 God Province (上 禹 省 ) 的 邮 
件 都 必须 进行 安全 检查 ， 那 我 们 束 很 好 处 理 了 ， 如 图 23-3 所 示 。 
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Hvoid sendLetter(Strng context Strmg address) 
























图 23-3 扩展 后 的 系统 类 图 


增加 了 一 个 Police 类 ， 负 责 对 信件 进行 检查 ， 如 代码 清单 23-6 所 


代码 清单 23-6 信件 检查 类 


public class Police { 
// 检 查 信 件 ， 检 查 完毕 后 警察 在 信封 上 新 个 稚 : 此 信和 无 病毒 
public void checkLetter(ILetterProcess letterProcess)t 
System.out.printlin(letterProcess+" 信件 已 经 检查 过 了 .,.." 
} 











我 们 再 来 看 一 下 封装 类 ModenPostOffice 的 变更 ， 它 封装 了 这 部 分 的 


变化 ， 如 代码 清单 23-7 所 示 。 


代码 清单 23-7 扩展 后 的 现代 化 邮局 


public class ModenPostoffice { 
private ILetterProcess letterProcess = new LetterProcessIimpl 
private Police letterPolice = new Police(); 
// 写 信 ， 封 装 ， 投 递 ， 一 体 化 了 


public void sendLetter(String context,String address){ 





// 帮 你 写 信 


letterProcess.writeContext(context); 


// 写 好 信封 





letterprocess.fillenvelope(address),; 
// 警 察 要 检查 信件 了 
letterPolice.checkLetter(letterProcess); 





// 把 信 放 到 信 








封 中 


letterProcess.1letterIinotoEnvelope( ); 


// 邮 递 信件 





letterProcess.sendLetter(); 


只 是 增加 了 一 个 letterPolice 变 量 的 声明 以 及 一 个 方法 的 调用 ， 那 这 
个 写 信 的 过 程 就 变 成 这 样 : 先 写 信 、 写 信封 ， 然 后 警察 开始 检查 ， 之 后 














才 把 信 放 到 信封 ， 最 后 发 送出 去 ， 那 这 个 变更 对 客户 来 说 是 透明 的 ， 他 
根本 就 看 不 到 有 人 在 检查 他 的 邮件 ， 他 也 不 用 了 解 ， 反 正 现代 化 的 邮件 
系统 都 帮 他 做 了 ， 这 也 是 他 乐意 的 地 方 。 





场景 类 还 是 完全 相同 ， 但 是 运行 结果 稍 有 不 同 ， 如 下 所 示 : 


填写 信 的 内 容 ...Hello,It's me,do you know who Iam?Tm your old lover.Td like to... 


填写 收 件 人 地 址 及 姓名 ...Happy Road No.666,God Province,Heaven 


com.cbf4life.common3.LetterProcessImpl@15ff48b 信件 已 经 检查 过 了 





把 信 放 到 信封 中 .… 


邮递 信件 .… 





高 层 模块 没有 任何 改动 ， 但 是 信件 却 已 经 被 检查 过 了 。 这 正 是 我 们 
设计 所 需要 的 模式 ， 不 改变 子 系统 对 外 暴露 的 接口 、 方 法 ， 只 改变 内 部 
的 处 理 罗 辑 ， 其 他 兄 加 模块 的 调用 产生 了 不 同 的 结果 ， 人 确实 是 一 个 非 闻 
棒 的 设计 。 这 就 是 门面 模式 。 





23.2 门面 模式 的 定义 


门面 模式 (Facade Pattern) 也 叫做 外 观 模式 ， 是 一 种 比较 党 用 的 封 
装 模 式 ， 其 定义 如 下 : 


Provide a unified interface to a set of interfaces in a subsystem.Facade 
defines a higher-level interface that makes the subsystem easier to use. (要 
求 一 个 子 系统 的 外 部 与 其 内 部 的 通信 必须 通过 一 个 统一 的 对 象 进 行 。 
面 模式 提供 一 个 高 层次 的 接口 ， 使 得 子 系统 更 易于 使 用 。 





门面 模式 注重 “统一 的 对 象 ”， 也 就 是 提供 一 个 访问 子 系统 的 接口 ， 
除了 这 个 接口 不 允许 有 任何 访问 子 系统 的 行为 发 生 ， 其 通用 类 图 ， 如 图 
23-4 上 所 示 。 



















Subsystem Classes 
ee 
EE 


图 23-4 扩展 后 的 系统 类 图 





是 的 ， 类 图 就 这 么 简单 ， 但 是 它 代 表 的 意义 可 是 异常 复杂 ， 
Subsystem Classes 是 子 系统 所 有 类 的 简称 ， 它 可 能 代表 一 个 类 ， 也 可 能 
代表 几 十 个 对 象 的 集合 。 硕 管 多 少 对 象 ， 我 们 把 这 些 对 象 全 部 圈 入 子 系 
统 的 范畴 ， 其 结构 如 图 23-5 所 示 。 


Facade 


十 
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图 23-5 门面 模式 示意 图 


再 简单 地 说 ， 门 面 对 象 是 外 界 访问 子 系统 内 部 的 唯一 通道 ， 不 管子 
系统 内 部 是 多 么 杂乱 无 革 ， 只 要 有 门面 对 象 在 ， 就 可 以 做 到 “金玉 其 
外 ， 败 妹 其 中 ”。 我 们 先 明 确 一 下 门面 模式 的 角色 。 








e Facade 门 面 角色 


客户 端 可 以 调用 这 个 角色 的 方法 。 此 角色 知晓 子 系统 的 所 有 功能 和 
责任 。 一 般 情况 下 ， 本 角色 会 将 所 有 从 客户 端 发 来 的 请 求 委 派 到 相应 的 
子 系统 去 ， 也 就 说 该 角色 没有 实际 的 业务 逻辑 ， 只 是 一 个 委托 类 。 








e@ subsystem 子 系统 角色 


可 以 同时 有 一 个 或 者 多 个 子 系统 。 每 一 个 子 系统 都 不 是 一 个 单独 的 
， 而 是 一 个 类 的 集合 。 子 系统 并 不 知道 门面 的 存在 。 对 于 子 系统 而 
， 门 面 仅仅 是 另外 一 个 客户 端 而 已 。 





氏 





了 上 


我 们 来 看 一 下 门面 模式 的 通用 源码 ， 先 来 看 子 系统 源 代 码 。 由 于 子 
系统 是 类 的 集合 ， 因 此 要 描述 该 集合 很 花费 精力 ， 每 一 个 子 系统 都 不 相 
同 ， 我 们 使 用 3 个 相互 无 关 的 类 来 代表 ， 如 代码 清单 23-8 所 示 。 


代码 清单 23-8 子 系统 


public class ClassA { 
public void doSomethingA( ){ 
// 业 务 逻 辑 
} 


} 
public class ClassB { 





public void doSomethingB()t{ 
// 业 务 逻 辑 
} 


} 
public class ClassC { 

















public void doSomethingC(){ 


// 业 务 逻 辑 





我 们 认为 这 3 个 类 属于 近邻 ， 处 理 相 关 的 业务 ， 因 此 应 该 被 认为 是 
一 个 子 系统 的 不 同 逻 辑 处 理 模块 ， 对 于 此 子 系统 的 访问 需要 通过 门面 进 
行 ， 如 代码 清单 23-9 所 示 。 


代码 清单 23-9 门面 对 象 


public class Facade { 

// 被 委托 的 对 象 

private ClassA a = new ClassA(); 

private ClassB b = new ClassB(); 

private ClassC c = new ClassC(); 

// 提 供给 外 部 访问 的 方法 

public void methodA(){ 
this.a.doSomethingA( ); 

} 


public void methodB(){ 
this.b.doSsomethingB( ); 
} 


public void methodCc(){ 
this.c.doSomethingC( ); 
} 

















23.3 门面 模式 的 应 用 


23.3.1 门面 模式 的 优点 


门面 模式 有 如 下 优点 。 


e 减少 系统 的 相互 依赖 





想 想 看 ， 如 果 我 们 不 使 用 门面 模式 ， 外 界 访问 直接 深入 到 子 系统 内 
部 ， 相 互 之 间 是 一 种 强 耦 合 关 系 ， 你 死 我 就 死 ， 你 活 我 才能 活 ， 这 样 的 
强 依赖 是 系统 设计 所 不 能 接受 的 ， 门 面 模式 的 出 现 就 很 好 地 解决 了 访问 
题 ， 所 有 的 依赖 都 是 对 门面 对 象 的 依赖 ， 与 子 系统 无 关 。 


e 所 高 了 灵活 性 


依赖 减少 了 ， 灵 活性 自然 提高 了 。 不 管子 系统 内 部 如 何 变 化 ， 只 要 
不 影响 到 门面 对 象 ， 任 你 自由 活动 。 





e 提高 安全 性 


想 让 你 访问 子 系统 的 哪些 业务 就 开通 哪些 思 辑 ， 不 在 门面 上 开通 的 
方法 ， 你 休想 访问 到 。 


23.3.2 门面 模式 的 缺点 


门面 模式 最 大 的 缺点 就 是 不 符合 开 闭 原则 ， 对 修改 关闭 ， 对 扩展 开 
放 ， 看 看 我 们 那个 门面 对 象 吧 ， 它 可 是 重 中 之 重 ， 一 旦 在 系统 投产 后 发 
现 有 一 个 小 错误 ， 你 怎么 解决 ? 完全 遵从 开 闭 原则 ， 根 本 没 办 法 解雇 。 
继承 ? 履 写 ? 都 项 不 上 用 ， 唯 一 能 做 的 一 件 事 就 是 修改 门面 角色 的 代 
码 ， 这 个 风险 相当 大 ， 这 就 需要 大 家 在 设计 的 时 候 慎 之 又 愤 ， 多 思考 几 
角 才 会 有 好 收获 。 








23.3.3 门面 模式 的 使 用 场景 


e 为 一 个 复杂 的 模块 或 子 系统 提供 一 个 供 外 界 访问 的 接口 


e 于 系统 相对 独立 一 一 外 界 对 子 系统 的 访问 只 要 黑箱 操作 即 可 





比如 利明 的 计算 问题 ， 没 有 深厚 的 业务 知识 和 扎实 的 技术 水 平 是 不 
可 能 开发 出 该 子 系统 的 ， 但 是 对 于 使 用 该 系统 的 开 及 人 员 来 说 ， 他 需要 
做 的 束 是 输入 金额 以 及 存 期 ， 其 他 的 都 不 用 关心 ， 返 回 的 结果 就 是 利 
恩 ， 这 时 候 ， 门 面 模式 是 非 使 用 不 可 了 。 


e 预防 低 水 平 人 员 市 来 的 风险 扩散 





比如 一 个 低 水 平 的 技术 人 员 参 与 项 目 开发 ， 为 降低 个 人 代码 质量 对 
整体 项 目的 影响 风险 ， 一 般 的 做 法 是 “ 男 地 为 牢 ”， 只 能 在 指定 的 子 系统 





中 开发 ， 然 后 再 提供 门面 接口 进行 访问 操作 。 


23.4 门面 模式 的 注意 事项 





23.4.1 一 个 子 系统 可 以 有 多 个 门面 


一 般 情 况 下 ， 一 个 子 系统 只 要 有 一 个 门面 足够 了 ， 在 什么 情况 下 一 
个 子 系统 有 多 个 门面 呢 ? 以 下 列举 了 几 个 。 








e 门面 已 经 庞大 到 不 能 忍受 的 程度 


比如 一 个 纯洁 的 门面 对 象 已 经 超过 了 200 行 的 代码 ， 虽 然 都 是 非常 
简单 的 委托 操作 ， 也 建议 拆 分 成 多 个 门面 ， 否 则 会 给 以 后 的 维护 和 扩展 
融 来 不 必要 的 叹 烦 。 那 怎么 拆 分 呢 ? 按照 功能 拆 分 是 一 个 非 利 好 的 原 
则 ， 比 如 一 个 数据 库 操 作 的 门面 可 以 拆 分 为 查询 门面 、 删 除 门面 、 更 新 
门面 等 。 











。 子 系统 可 以 提供 不 同 访问 路 径 


我 们 以 门面 模式 的 通用 源 代码 为 例 。ClassA、ClassB、ClassC 是 一 
个 子 系统 的 中 3 个 对 象 ， 现 在 有 两 个 不 同 的 高 层 模 块 来 访问 该 子 系统 ， 
模块 一 可 以 完整 的 访问 所 有 业务 逻辑 ， 也 就 是 通用 代码 中 的 Facade 类 ， 
它 是 子 系统 的 信任 模块 ;而 模块 二 属于 受 限 访问 对 象 ， 只 能 访问 
methodB 方 法 ， 那 该 如 何 处 理 呢 ? 在 这 种 情况 下 ， 就 需要 建立 两 个 门面 








以 供 不 同 的 高 层 模块 来 访问 ， 在 原 有 的 通用 源码 上 增加 一 个 新 的 门面 即 
可 ， 如 代码 清单 23-10 所 示 。 


代码 清单 23-10 新 增 门面 


public class Facade2 { 
// 引 用 原 有 的 门面 
private Facade facade = new Facade( ); 
// 对 外 提供 唯一 的 访问 子 系统 的 方法 
public void methodB( ){ 
this.facade.methodB( ); 
} 

















增加 的 门面 非常 简单 ， 委 托 给 了 已 经 存在 的 门面 对 象 Facade 进 行 处 
理 ， 为 什么 要 使 用 委托 而 不 再 编写 一 个 委托 到 子 系统 的 方法 呢 ? 那 是 因 
为 在 面 加 对 象 的 编程 中 ， 尺 量 保 持 相 同 的 代码 只 编写 一 这， 避免 以 后 到 
处 修改 相似 代码 的 翡 剧 。 


23.4.2 门面 不 参与 子 系统 内 的 业务 逻辑 


我 们 这 节 的 标题 是 什么 意思 呢 ? 我 们 举 一 个 例子 来 说 明 ， 还 是 以 通 
用 源 代 码 为 例 。 我 们 把 门面 上 的 methodC 上 的 逻辑 修改 一 下 ， 它 必须 先 
调用 ClassA 的 doSomethingA 方 法 ， 然 后 再 调用 ClassC 的 doSomethingC 方 
法 ， 如 代码 清单 23-11 所 示 。 


代码 清单 23-11 修改 门面 


public class Facade { 


// 被 委托 的 对 象 
private ClassA a = new ClassA(); 
private ClassB b = new ClassB(); 
private ClassC c = new ClassC(); 
// 提 供给 外 部 访问 的 方法 
public void methodA(){ 
this.a.doSomethingA( ); 
} 


public void methodB(){ 
this.b.doSsomethingB( ); 
} 


public void methodCc(){ 
this.a.doSomethingA( ); 
this.c.doSomethingC( ); 

















还 是 非常 简单 ， 只 是 在 methodC 方 法 中 增加 了 doSomethingA(O 方 法 
的 调用 ， 可 以 这 样 做 吗 ? 我 相信 大 部 分 读者 都 说 可 以 这 样 做 ， 而 且 已 经 
在 实际 系统 开发 中 这 样 使 用 了， 我 今天 告诉 各 位 ， 这 样 设计 是 非常 不 靠 
谱 的 ， 为 什么 呢 ? 因 为 你 已 经 让 门面 对 象 参与 了 业务 逻辑 ， 门 面 对 象 只 
是 提供 一 个 访问 子 系统 的 一 个 路 径 而 已 ， 它 不 应 该 也 不 能 参与 具体 的 业 
务 馆 辑 ， 人 否则 就 会 产生 一 个 倒 依赖 的 问题 : 子 系统 必须 依赖 门面 才能 被 
访问 ， 这 是 设计 上 一 个 严重 错误 ， 不 仅 违 反 了 单一 职 黄 原则， 同时 也 破 
坏 了 系统 的 封装 性 。 








说 了 这 么 多 ， 那 对 于 这 种 情况 该 怎么 处 理 呢 ? 建立 一 个 封装 类 ， 封 
装 完 毕 后 提供 给 门面 对 象 。 我 们 移 建立 一 个 封装 类 ， 如 代码 清单 23-12 
所 示 。 


代码 清单 23-12 封装 类 


public class Context { 

// 委 托 处 理 

private ClassA a = new ClassA(); 

private ClassC c = new ClassC(); 

// 复 杂 的 计算 

public void complexMethod(){ 
this.a.doSomethingA( ); 
this.c.doSomethingC( ); 




















该 封装 类 的 作用 就 是 产生 一 个 业务 规则 complexMethod， 并 且 它 的 
生存 环境 是 在 子 系统 内 ， 仅 仅 依赖 两 个 相关 的 对 象 ， 门 面 对 象 通过 对 它 
的 访问 完成 一 个 复杂 的 业务 逻辑 ， 如 代码 清单 23-13 所 示 。 


代码 清单 23-13 门面 类 


public class Facade { 

// 被 委托 的 对 象 

private ClassA a = new ClassA(); 

private ClassB b = new ClassB(); 

private Context context = new Context(); 

// 提 供给 外 部 访问 的 方法 

public void methodA(){ 
this.a.doSomethingA( ); 

} 


public void methodB(){ 
this.b.doSsomethingB( ); 
} 


public void methodc()t{ 
this.context.complexMethod( ); 
} 

















通过 这 样 一 次 封装 后 ， 门 面 对 象 又 不 参与 业务 馆 辑 了 ， 在 门面 模式 
中 ， 门 面 角色 应 该 是 稳定 ， 它 不 应 该 经 常 变化 ， 一 个 系统 一 旦 投入 运行 








它 就 不 应 该 被 改变 ， 它 是 一 个 系统 对 外 的 接口 ， 你 变 来 变 去 还 怎么 保证 
其 他 模块 的 稳定 运行 呢 ? 但 是 ， 业 务 人 好 辑 是 会 经 常 变化 的 ， 我 们 已 经 把 
它 的 变化 封 效 在 子 系统 内 部 ， 无 论 你 如 何 变 化 ， 对 外 界 的 访问 者 来 说 ， 
都 还 是 同一 个 门面 ， 同 样 的 方法 一 一 这 才 是 染 构 师 最 希望 看 到 的 结构 。 





23.5 最 佳 实践 


门面 模式 是 一 个 很 好 的 封装 方法 ， 一 个 子 系统 比较 复杂 时 ， 比 如 算 
法 或 者 业务 比较 复 汪 ， 束 可 以 封 效 出 一 个 或 多 个 门面 出 来 ， 项 目的 结构 
简单 ， 而 且 扩展 性 非常 好 。 还 有 ， 对 于 一 个 较 大 项 目 ， 为 了 避免 人 员 带 
来 的 风险 ， 也 可 以 使 用 门面 模式 ， 技 术 水 平 比较 兰 的 成 员 ， 尽 量 安排 独 
芯 的 模块 ， 然 后 把 他 写 的 程序 封装 到 一 个 门面 里 ， 尽 量 让 其 他 项 目 成 员 
不 用 看 到 这 些 人 的 代码 ， 看 也 看 不 懂 ， 我 也 遇 到 过 一 个 “高 人 ” 写 的 代 
码 ，private 方 法 、 构 造 函 数 、 常 量 基本 都 不 用 ， 你 要 一 个 public 方 法 ， 
好 ， 一 个 类 里 就 一 个 public 方 法 ， 所 有 代码 都 在 里 面 ， 然 后 你 就 看 吧 ， 
一 大 老 程 序 ， 看 独 就 能 把 人 逼 疡 。 使 用 门面 模式 后 ， 对 门面 进行 单元 测 
试 ， 约 束 项 目 成 员 的 代码 质量 ， 对 项 目 整 体质 量 的 提升 也 是 一 个 比较 好 
的 帮助 。 




















第 24 革 备 态 录 模 式 


24.1 如 此 追 女 孩子 ， 你 还 不 乐 


大 家 有 没有 看 过 尼古拉斯 - 凯 奇 主演 的 《Next》〈 中 文 译名 为 《 预 
见 未 来 》) ? 尼古拉斯 : 凯 奇 饰演 一 个 可 以 预 视 并 且 扭 转 未 来 的 人 ， 其 
中 有 一 个 情节 很 是 让 人 心动 一 一 男女 主角 见面 的 那 段 情节 : Cris 
Johnson〔 尼 上 古 拉 斯 - 凯 奇 饰演 ) 坐 在 咖啡 吧台 前 ， 看 着 离 自己 近 在 个 尺 
的 Callie Ferris( 朱 莉 安 :摩尔 饰演 ) ， 计 划 着 怎么 认识 这 个 命中 注定 的 
女人 ， 看 Cris Johnson 如 何 利 用 自己 的 特异 功能 : 











e Cris Johnson 闻 着 一 杯 咖 啡 走 过 去 ， 说 “你 好 ， 可 以 认识 你 吗 ? ”被 
拒绝 ， 恢 复 到 坐 在 咖啡 吧台 前 的 状态 。 


e 走 过 去 询问 是 人 否 可 以 搭车 ， 被 拒绝 ， 恢 复原 状 。 


e 帮助 解决 困境 ， 被 拒绝 ， 恢 复原 状 。 


e 采用 娩 育 士 的 方式 解决 困 声 ， 科 拒绝 ， 恢 复原 状 。 


e 帮助 解决 困境 ， 被 打 伤 ， 闭 可 怜 ，Callie Ferris 怜 惜 ， 于 是 手相 识 


看 看 这 是 一 件 多 么 笠 福 的 事情 ， 退 求 一 个 女生 可 以 多 次 反复 地 实 
验 ， 直 到 找到 好 的 方法 和 途径 为 止 ， 这 估计 是 大 多 数 男 生 都 希望 获得 的 
特异 功能 。 想 想 看 ， 看 到 一 个 心仪 的 女生 ， 我 们 大 有 反复 尝试 ， 总 会 有 一 
个 方法 打动 她 的 ， 多 美好 的 一 件 事 。 现 在 我 们 还 得 回 到 现实 生活 ， 我 们 
来 分 析 一 下 类 似 事情 的 经 过 : 





e 复制 一 个 当前 状态 ， 保 留 下 来 ， 这 个 状态 就 是 等 会 儿 搭 训 女 孩子 
失败 后 要 恢复 的 状态 ， 你 不 恢复 原始 状态 ， 这 不 束 露 馅 儿 了 吗 ? 

















e 每 次 试探 性 尝试 失败 后 ， 都 必须 恢复 到 这 个 原始 状态 。 


e N 次 试探 总 有 一 次 成 功 吧 ， 成 功 以 后 即 可 走 成 功 路 线 。 





想 想 看 ， 我 们 这 里 的 场景 中 最 重要 的 是 哪 一 块 ? 对 的 ， 是 原始 状态 
的 保留 和 恢复 这 块 ， 如 何 保 留 一 个 原始 ， 如 何 恢复 一 个 原始 状态 才 是 最 
重要 的 ， 那 想 想 看 ， 我 们 应 该 怎么 实现 呢 ? 很 简单 呀 ， 我 们 可 以 定义 一 
个 中 间 变 量 ， 保 留 这 个 原始 状态 。 我 们 先 看 看 类 图 ， 如 图 24-1 所 示 。 









Client 
+Vold changeState() 
+Strng getState() 
+Vold setState(String state) 


图 24-1 男孩 状态 类 图 


太 简 单 的 类 图 了 ， 我 们 来 解释 一 下 图 中 的 状态 state 是 什么 意思 ， 在 
茶 一 时 间 扣 的 所 有 位 置信 息 、 心 理 信息 、 环 境 信息 都 属于 状态 ， 我 们 这 
里 用 了 一 个 标识 性 的 名 词 state 代 表 所 有 状态 ， 比 如 在 追 女 孩子 前 心情 是 
期 待 、 心 理 是 焦躁 不 安 等 。 每 一 次 去 认识 女孩 子 都 是 会 发 生 状 态 变化 
的 ， 我 们 使 用 changeState 方 法 来 代 谷 ， 由 于 程序 比较 简单 ， 束 没有 编写 
接口 ， 我 们 来 看 实现 ， 如 代码 清单 24-1 所 示 。 





代码 清单 24-1 男孩 状态 类 


public class Boy { 
// 男 孩 的 状态 
private String state = ""; 
// 认 识 女 孩子 后 状态 肯定 改变 ， 比 如 心情 、 手 中 的 花 等 
public void changeState( ){ 
this.state = "心情 可 能 很 不 好 "， 
} 


























public String getState() { 


return State， 


public void setState(String state) { 


} 


this.state = state,; 





程序 是 很 简单 ， 主 要 的 业务 逻辑 是 在 场景 类 中 ， 我 们 来 看 场景 类 是 
如 何 进行 状态 的 保留 、 恢 复 的 ， 如 代码 清单 24-2 所 示 。 


代码 清单 24-2 场景 类 


public class Client { 
public static void main(String[] args) { 


// 声 明 出 主角 

Boy boy = new Boy(); 

// 初 始 化 当前 状态 

boy ,setState(" 心 情 很 棒 ! "); 
System.out,.println("===== 男 孩 现在 的 状态 ======" ) ， 
System.out.println(boy.getSstate()); 

// 需 要 记录 下 当前 状态 呀 

Boy backup = new Boy(); 
backup.setState(boy.getstate( )); 

// 男 孩 去 妃 女 孩 ， 状 态 改 变 

boy.changeState( ); 

System.out.printlin("\n===== 男 孩 追 女孩 子 后 的 状态 ======") 
System.out.println(boy.getSstate()); 

// 仍 女孩 失败 ， 恢 复原 状 
boy.setState(backup.getstate( )); 
System.out.println("\n===== 男 孩 恢 复 后 的 状态 ======" ) ; 
System.out.println(boy.getSstate()); 










































































程序 运行 结果 如 下 所 示 : 


心情 很 棒 ! 


















































心情 很 棒 ! 





程序 运行 正确 ， 输 出 结果 也 是 我 们 期 望 的 ， 但 是 结果 正确 并 不 表示 
程序 是 最 优 的 ， 我 们 来 看 看 场景 类 Client， 它 代表 的 是 高 层 模 块 ， 或 者 
说 是 非 “ 近 杀 ” 模 块 的 调用 者 ， 注 意 看 backup 变 量 的 使 用 ， 它 对 于 高 层 模 
块 完 全 是 多 余 的 ， 为 什么 一 个 状态 的 保存 和 恢复 要 让 高 层 模块 来 负责 
呢 ? 这 应 该 是 Boy 类 的 职责 ， 而 不 应 该 让 高 层 模块 来 完成 ， 也 就 是 破坏 
了 Boy 类 的 封装 ， 或 者 说 Boy 类 没有 封装 好 ， 筷 应 该 是 把 backup 的 定义 
容纳 进来 ， 而 不 应 该 让 高 层 模块 来 定义 。 






































问题 我 们 已 经 知道 了 上， 就 是 Boy 类 封装 不 够 ， 那 我 们 应 该 如 何 修改 
呢 ? 如 果 在 Boy 类 中 再 增加 一 个 方法 或 者 其 他 的 内 部 类 来 保存 这 个 状 
态 ， 则 对 单一 职责 原则 是 一 种 破坏 ， 想 想 看 单一 职责 原则 是 怎么 说 的 ? 
一 个 类 的 职责 应 该 是 单一 的 ，Boy 类 本 号 的 职责 是 退 求 女孩 子 ， 而 保留 
和 恢复 原始 状态 则 应 该 由 兄 外 一 个 类 来 承担 ， 那 我 们 把 这 个 类 取 名 惑 叫 
做 备 迄 录 ， 这 和 大 家 经 种 在 桌面 上 贴 的 那个 便签 是 一 个 概 您 ， 分 析 到 这 
里 我 们 的 思路 已 经 非常 清楚 了 ， 我 们 来 修改 一 下 类 图 ， 如 图 24-2 所 示 。 






-Strimg state 


+void change State() 

+String getState() 

+void SetState(String state) 

+Memento create Memento() 

+Vold restore Memento(Memento memento) 






Client 


图 24-2 完善 后 的 男孩 状态 类 图 


改动 很 小 ， 增 加 了 一 个 新 的 类 Memento， 负 责 状 态 的 保存 和 备份 ; 
同时 ， 在 Boy 类 中 增加 了 创建 一 份 备 忘 录 createMemento 和 恢复 一 个 备 坊 
录 resotreMemento， 我 们 先 来 看 Boy 类 的 变化 ， 如 代码 清单 24-3 所 示 。 


代码 清单 24-3 改进 后 的 男孩 状态 类 


public class Boy { 
// 男 孩 的 状态 
private String state = ""; 
// 认 识 女 孩子 后 状态 肯定 改变 ， 比 如 心情 、 手 中 的 花 等 
public void changeState(){ 
this.state = "心情 可 能 很 不 好 "; 


























} 
public String getState() { 
return state; 


} 
public void setState(String state) { 
this.state = state,; 


} 
// 保 留 一 个 备份 





public Memento createMemento( ){ 
return new Memento(this.state); 


} 

// 恢 复 一 个 备份 

public void restoreMemento(Memento _memento){ 
this.SsetState(_memento.getState() ) ; 

} 


注意 看 ， 确 实 只 增加 了 两 个 方法 创建 备份 和 恢复 备份 ， 至 于 在 什么 
时 候 创建 备份 和 恢复 备份 则 是 由 高 层 模 块 决 定 的 。 我 们 再 来 看 备 厄 录 模 
块 ， 如 代码 清单 24-4 所 示 。 








代码 清单 24-4 备忘录 


public class Memento { 
// 男 孩 的 状态 
private String state = ""; 
// 通 过 构造 函数 传递 状态 信息 
public Memento(String _state)t{ 
this.state = _state; 




















} 
public String getState() { 
return state; 


public void setState(String state) { 
this.state = state,; 
} 


这 惑 是 一 个 简单 的 JavaBean， 保 留 男孩 当时 的 状态 信息 。 我 们 再 来 
看 场景 类 ， 稍 做 修改 ， 如 代码 清单 24-5 所 示 。 


代码 清单 24-5 改进 后 的 场景 类 


public class Client { 
public static void main(String[] args) { 


// 声 明 出 主角 


Boy boy = new Boy( ) ; 

// 初 始 化 当前 状态 

boy,setState(" 心 情 很 棒 ! ") ， 
System.out,printJIn("===== 男 孩 现在 的 状态 ======" ) ， 
System.out,.println(boy.getState() ) ， 

// 需 要 记录 下 当前 状态 呀 

Memento mem = boy,createMemento( ) 

// 男 孩 去 追 女 孩 ， 状 态 改变 

boy.changeState( ); 

System.out .println("\n===== 男 孩 追 女孩 子 后 的 状态 ======") 
System.out.println(boy.getSstate( )); 

// 追 女孩 失败 ， 恢 复原 状 

boy.restoreMemento(mem); 
System.out.println("\n===== 男 孩 恢 复 后 的 状态 ======" ) ; 
System.out.println(boy.getSstate( )); 
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运行 结果 保持 相同 ， 虽 然 程序 中 不 再 重复 定义 Boy 类 的 对 象 了 ， 但 
是 我 们 还 是 要 关心 备 态 录 ， 这 对 迪 米 特 法 则 是 一 个 歼 渎 ， 它 告诉 我 们 只 
和 朋友 类 通信 ， 那 这 个 备 扎 录 对 象 是 我 们 必须 要 通信 的 朋友 类 吗 ? 对 蜗 
层 模 块 来 说 ， 它 最 希望 要 做 的 吏 是 创建 一 个 备份 点 ， 然 后 在 需要 的 时 候 
再 恢复 到 这 个 备份 点 号 成 了 ， 它 不 用 关心 到 确 有 没有 备忘录 这 个 类 。 那 
根据 这 一 指导 思想 ， 我 们 束 需 要 把 备 扎 录 类 再 包装 一 下 ， 怎 么 包 六 呢 ? 
建立 一 个 省 理 类 ， 就 是 省 理 这 个 备 态 录 ， 如 图 24-3 所 示 。 







-String state 


+void changeState() 

+String getState() 

+void setState(String state) 

+Memento createMemento() 

+void restore Memento(Memento _memento) 





Client 





图 24-3 完整 的 男孩 追 女生 类 图 


又 增加 了 一 个 JavaBean，Boy 类 和 Memento 没 有 任何 改变 ， 不 再 痪 
述 。 我 们 来 看 增加 的 备 瑟 录 管 理 类 ， 如 代码 清单 24-6 所 示 。 


代码 清单 24-6 备忘录 管理 者 


public class Caretaker { 
// 和 备忘录 对 象 
private Memento memento; 
public Memento getMemento() { 
return memento; 


public void setMemento(Memento memento) { 
this.memento = memento; 
} 


这 个 太 简 单 了 ， 非 常 纯粹 的 一 个 JavaBean， 表 管 它 多 简单 ， 只 要 有 
用 就 成 ， 我 们 来 看 场景 类 如 何 调 用 ， 如 代码 清单 24-7 所 示 。 


代码 清单 24-7 进一步 改进 后 的 场景 类 


public class Client { 

public static void main(String[|] args) { 
// 声 明 出 主角 
Boy boy = new Boy() ， 
// 声 明 出 备忘录 的 管理 者 
Caretaker caretaker = new Caretaker(); 
// 初 始 化 当前 状态 
boy .setstate(" 心 情 很 棒 !"); 
System.out,.println("===== 男 孩 现在 的 状态 ======" )，; 
System.out.println(boy.getSstate()); 
// 需 要 记录 下 当前 状态 呀 
caretaker .setMemento(boy .createMemento( ) ) ; 
// 男 孩 去 妃 女 孩 ， 状 态 改 变 
boy.changeState( ); 
System.out.printlin("\n===== 男 孩 追 女孩 子 后 的 状态 ======" ) ， 

























































































System.out,println(boy,.getState() ) ; 

// 妃 女孩 失败 ， 恢 复原 状 

boy ,restoreMemento(caretaker .getMemento( ) ) ， 
System.out.printlLn("NXn===== 男 孩 恢 复 后 的 状态 ======" 
System.out.println(boy.getSstate()); 























注意 看 黑体 部 分 ， 残 修改 了 这 么 多 ， 看 看 程序 的 多 辑 是 不 是 清晰 了 
很 多 ， 需 要 备份 的 时 候 就 创建 一 个 备份 ， 然 后 丢 给 备 筷 录 管 理 者 进行 管 
理 ， 要 取 的 时 候 再 从 管理 者 手中 全 到 这 个 备份 。 这 个 备份 者 就 类 似 于 一 
个 备份 的 仓库 管理 员 ， 创 建 一 个 丢 进 去 ， 需 要 的 时 候 再 拿 出 来 。 这 就 是 
备 捷 录 模 式 。 





24.2 备 态 录 模 式 的 定义 
备忘录 模式 (Memento Pattern) 提供 了 一 种 弥补 真实 世界 缺陷 的 方 
法 ， 让 “后 悔 药 ”在 程序 的 世界 中 真实 可 行 ， 其 定义 如 下 : 


Without violating encapsulation,capture and externalize an object's 
internal state so that the object can be restored to this state later. 《在 不 破坏 
封装 性 的 前 提 下 ， 捕 获 一 个 对 象 的 内 部 状态 ， 并 在 该 对 象 之 外 保存 这 个 
状态 。 这 样 以 后 就 可 将 该 对 象 恢 复 到 原先 保存 的 状态 。 ) 

通俗 地 说 ， 备 忘 录 模 式 就 是 一 个 对 象 的 备份 模式 ， 提 供 了 一 种 程序 
数据 的 备份 方法 ， 其 通用 类 图 如 图 24-4 所 示 。 


Memento 
| 
+SetMemento(m: Memento) 
+Create Memento() 


+GetState() 
图 24-4 备 坏 录 模 式 的 通用 类 图 





















+menento 


+SetState() 





我 们 来 看 看 类 图 中 的 三 个 角色 。 
e Originator 发 起 人 角色 


记录 当前 时 刻 的 内 部 状态 ， 负 责 定义 哪些 属于 备份 范围 的 状态 ， 负 


员 创 建 和 恢复 备 扎 录 数 据 。 


e Memento 和 备忘录 角色 





负责 存储 Originator 发 起 人 对 象 的 内 部 状态 ， 在 再 要 的 时 候 提 供 发 起 
人 需要 的 内 部 状态 。 


e Caretaker 备 忘 录 管 理 员 角色 
对 备 瑟 录 进 行 管理 、 保 存 和 提供 备 坏 录 


备忘录 模式 的 通用 代码 也 非常 简单 ， 我 们 先 看 发 起 人 和 角色， 如 代码 
清单 24-8 所 示 。 


代码 清单 24-8 发 起 人 角色 


public class Originator { 
// 内 部 状态 


private String state = ""; 


public String getState() { 
return state; 


public void setState(String state) { 
this.state = state,; 


} 
// 创 建 一 个 备 态 录 
public Memento createMemento( ){ 
return new Memento(this.state); 


} 

// 恢 复 一 个 备忘录 

public void restoreMemento(Memento _memento)t{ 
this.setState(_memento.getState()); 

} 





我 相信 你 心里 此 刻 有 很 多 疑问 ， 比 如 状态 是 多 个 怎么 办 ? 需要 有 多 
份 备份 怎么 办 ? 如 果 你 很 着 急 的 话 ， 请 看 24.4 六 ， 但 我 建议 你 还 是 跟随 
我 一 步 一 步 地 走 ， 我 们 再 来 看 备忘录 角色 ， 如 代码 清单 24-9 所 示 。 





代码 清单 24-9 备忘录 角色 


public class Memento { 
// 发 起 人 的 内 部 状态 
private String state = ""; 
// 构 造 函 数 传 递 参 数 
public Memento(String _state)t{ 
this.state = _state,; 


} 
public String getState() { 
return state; 


public void setState(String state) { 
this.state = state,; 
} 





这 是 一 | 简单 的 JavaBean, 备 访 录 管理 者 也 是 一 | 简单 的 JavaBean， 
如 代码 清单 24-10 所 示 。 


代码 清单 24-10 备 筷 录 管 理 员 和 角色 


public class Caretaker { 
// 和 备忘录 对 象 
private Memento memento; 
public Memento getMemento() { 
return memento; 


public void setMemento(Memento memento) { 
this.memento = memento; 
} 


这 3 个 主要 角色 都 很 简单 ， 我 们 来 看 场景 类 如 何 调用 ， 如 代码 清单 
24-11 所 示 。 


代码 清单 24-11 场景 类 


public class Client { 
public static void main(String[] args) { 

// 定 义 出 发 起 人 
Originator originator = new Originator(); 
// 定 义 出 备忘录 管理 员 
Caretaker caretaker = new Caretaker(); 
// 创 建 一 个 备 访 录 
caretaker.setMemento(originator.createMemento( ) ) ; 
// 恢 复 一 个 备忘录 
originator.restoreMemento(caretaker ,getMemento( )); 






































备 捷 录 模 式 束 是 这 么 简单 ， 真 正 使 用 备 息 录 模式 的 时 候 可 比 这 复杂 


24.3 备 访 录 模 式 的 应 用 





由 于 备忘录 模式 有 太 多 的 变形 和 处 理 方式 ， 每 种 方式 都 有 它 自己 的 
优点 和 缺点 ， 标 准 的 备 筷 录 模 式 很 难 在 项 目 中 遇 到 ， 基 本 上 都 有 一 些 变 
换 处 理 方式 。 因 此 ， 我 们 在 使 用 备 筷 录 模 式 时 主要 了 解 如 何 应 用 以 及 需 
要 注意 哪些 事项 就 成 了 。 





24.3.1 备 筷 录 模 式 的 使 用 场景 





e 需要 保存 和 恢复 数据 的 相关 状态 场景 。 


e 提供 一 个 可 回 深 〈rollback〉 的 操作 ; 比如 Word 中 的 CTRL+Z 组 合 
键 ， 正 浏览 器 中 的 后 退 按钮 ， 文 件 管理 器 上 的 backspace 键 等 。 


e 需要 监控 的 副本 场景 中 。 例 如 要 监控 一 个 对 象 的 属性 ， 但 是 监控 
又 不 应 该 作为 系统 的 主 业务 来 调用 ， 它 只 是 边缘 应 用 ， 即 使 出 现 监控 不 
准 、 错 误 报 警 也 影响 不 大 ， 因 此 一 般 的 做 法 是 备份 一 个 主线 程 中 的 对 
象 ， 然 后 由 分 析 程 序 来 分 析 。 


e 数据 库 连 接 的 事务 管理 就 是 用 的 备 还 录 模 式 ， 想 想 看 ， 如 果 你 要 
实现 一 个 JDBC 了 驱动 ， 你 怎么 来 实现 事务 ? 还 不 是 用 备 瑟 录 模 式 嘛 ! 


24.3.2 备 态 录 模 式 的 注意 事项 


e 备 挡 录 的 生命 期 





备忘录 创建 出 来 就 要 在 “最 近 ” 的 代码 中 使 用 ， 要 主动 管理 它 的 生命 
周期 ， 建 立 就 要 使 用 ， 不 使 用 就 要 立刻 删除 其 引用 ， 等 待 垃圾 回收 器 对 
它 的 回收 处 理 。 


e 备 去 录 的 性 能 


不 要 在 频 蚂 建立 备份 的 场景 中 使 用 备 起 录 模 式 〈 比 如 一 个 for 循 环 
中 ) ， 原 因 有 二 : 一 是 控制 不 了 备 起 录 建 立 的 对 象 数 量 ， 二 是 大 对 象 的 
建立 是 要 消耗 资源 的 ， 系 统 的 性 能 需要 考虑 。 因 此 ， 如 果 出 现 这 样 的 代 
码 ， 设 计 师 束 应 该 好 好 想 想 怎 么 修改 架构 了 。 





24.4 备 瑟 录 模 式 的 扩展 


24.4.1 clone 方 式 的 备忘录 





大 家 还 记得 在 第 13 章 中 讲 的 原型 模式 吗 ? 我 们 可 以 通过 复制 的 方式 
产生 一 个 对 象 的 内 部 状态 ， 这 是 一 个 很 好 的 办 法 ， 发 起 人 角色 只 要 实现 
Cloneable 就 成 ， 比 较 简 单 ， 我 们 来 看 类 图 ， 如 图 24-5 所 示 。 








: -Origmator originator 


i +Originator create Memento() i ici 
+void restoreMemento(Originator _originator) +Origmator getOriginator() 


+Originator clone() +void setOriginator(Originator origmator) 















图 24-5 Clone 方 式 的 备忘录 


从 类 图 上 看 ， 发 起 人 角色 融合 了 发 起 人 角色 和 备忘录 和 角色， 具有 双 
重 功效 ， 如 代码 清单 24-12 所 示 。 


代码 清单 24-12 融合 备 瓦 录 的 发 起 人 角色 


public class Originator implements Cloneablef 
// 内 部 状态 
private String state = ""; 


public String getState() { 
return state,; 


} 
public void setState(String state) { 
this.state = state,; 


} 

// 创 建 一 个 备 态 录 

public Originator createMemento( ){ 
return this.clone(); 


} 

// 恢 复 一 个 备 态 录 

public void restoreMemento(Originator _originator)t{ 
this.setState(_originator.getState( )); 


} 

// 克 隆 当 前 对 象 

@Override 

protected Originator clone(){ 


try { 





return (Originator)super.clone(); 
} catch (CloneNotSupportedException e) { 
e.printStackTrace( ); 


return null; 


增加 了 clone 方 法 ， 产 生 了 一 个 备份 对 象 ， 需 要 使 用 的 时 候 再 还 原 ， 
我 们 再 来 看 管理 员 角 色 ， 如 代码 清单 24-13 所 示 。 


代码 清单 24-13 备 厄 录 管 理 员 角色 


public class Caretaker { 
// 发 起 人 对 象 
private Originator originator ; 
public Originator getOriginator() { 
return originator; 


public void setOriginator(Originator originator) { 
this.originator = originator; 
} 


没什么 太 大 变化 ， 只 是 备 迄 录 角 色 转 换 成 了 发 起 人 角色 ， 还 是 一 个 
简单 的 JavaBean。 我 们 来 想 想 这 种 模式 是 不 是 还 可 以 简化 ? 要 管理 员 角 
色 干 什么 ? 就 是 为 了 管理 备 筷 录 角 色 ， 现 在 连 备 筷 录 角 色 都 被 合并 了 ， 
还 留 着 它 干 吗 ? 我 们 想 办 法 把 它 也 精简 掉 ， 如 代码 清单 24-14 所 示 。 


代码 清单 24-14 发 起 人 上 自主 备份 和 恢复 


public class Originator implements CloneabJlet 
private Originator backup; 
// 内 部 状态 
private String state = ""; 
public String getState() { 
return state,; 


public void setState(String state) { 
this.state = state,; 


// 创 建 一 个 备忘录 
public void createMemento( ){ 
this.backup = this,clone()， 


} 

// 恢 复 一 个 备 态 录 

public void restoreMemento( ){ 
// 在 进行 恢复 前 应 该 进行 断言 ， 防 止 空 指 针 
this.setState(this.backup.getSstate( )); 


} 

// 克 隆 当前 对 象 

Q@Override 

protected Originator clone(){ 


try { 











return (Originator)super.clone(); 
} catch (CloneNotSupportedException e) { 
e.printStackTrace( ); 
} 


return null; 





可 能 你 要 发 癌 了 ， 这 和 备 瑟 录 模 式 的 定义 不 相符 ， 它 定义 是 “在 该 


对 象 之 外 保存 这 个 状态 ”， 而 你 却 把 这 个 状态 保存 在 了 发 起 人 内 部 。 是 
的 ， 设 计 模 式 定义 的 诞生 比 Java 的 出 世 略 早 ， 它 没有 想到 Java 程 序 是 这 
么 有 活力 ， 有 远见 ， 而 且 在 面 同 对 象 的 设计 中 ， 即 使 把 一 个 类 封装 在 力 
一 个 类 中 也 是 可 以 做 到 的 ， 何 况 一 个 小 小 的 对 象 复制 ， 这 是 它 的 设计 模 
式 完 全 没有 预见 到 的 ， 我 们 把 它 弥补 回来 。 





再 来 看 看 Client 是 如 何 调用 的 ， 如 代码 清单 24-15 所 示 。 


代码 清单 24-15 场景 类 


public class Client { 
public static void main(String[|] args) { 

// 定 义 发 起 人 
Originator originator = new Originator(); 
// 建 立 初始 状态 
originator,setState(" 初 始 状态 , . ,") ， 
System.out.println(" 初 始 状态 是 : "+originator .getState( 
// 建 立 备 份 
originator .createMemento( ) ; 
// 修 改 状 态 
originator. a 
System.out .println(" 修 改 后 状态 是 : "+originator .getStatt 
// 恢 复原 有 状态 
originator.restoreMemento( ) ; 
System,out.println(" 恢 复 后 状态 是 : "+originator ,getStatt 














-一 


运行 结果 如 下 所 示 : 





初始 状态 是 :初始 状态 .… 
修改 后 状态 是 : 修改 后 的 状态 .…… 


恢复 后 状态 是 : 初始 状态 … 








运行 结果 是 我 们 所 希望 的 ， 程 序 精简 了 很 多 ， 而 且 高 层 模块 的 依赖 
也 减少 了 ， 这 正 是 我 们 期 望 的 效果 。 现 在 我 们 来 考虑 一 下 原型 模式 深 拷 
贝 和 浅 找 贝 的 问题 ， 在 复杂 的 场景 下 它 会 让 你 的 程序 逻辑 卉 党 混乱 ， 出 
现 错误 也 很 难 跟踪 。 因 此 Clone 方 式 的 备 二 录 模 式 适 用 于 较 简 单 的 场 





与. 
有 No 


注意 “使 用 Clone 方 式 的 备 瑟 录 模 式 ， 可 以 使 用 在 比较 简单 的 场景 
或 者 比较 单一 的 场景 中 ， 尽 量 不 要 与 其 他 的 对 象 产生 严重 的 耘 合 关 系 。 


24.4.2 多 状态 的 备 态 录 模 式 


读者 应 该 看 到 我 们 以 上 讲解 都 是 单 状态 的 情况 ， 在 实际 的 开发 中 一 
个 对 象 不 可 能 只 有 一 个 状态 ， 一 个 JavaBean 有 多 个 属性 非常 常见 ， 这 都 
古 它 的 状态 ， 如 条 照搬 我 们 以 上 讲解 的 备 生 录 模式 ， 是 不 是 就 要 与 一 扒 
的 状态 备份 、 还 原 语句 ?这 不 是 一 个 好 办 法 ， 这 种 类 似 的 非 智力 劳动 越 
多 ， 犯 错误 的 几率 越 大 ， 那 我 们 有 什么 办 法 来 处 理 多 个 状态 的 备份 问题 
呢 ? 

















下 面 我 们 来 讲解 一 个 对 象 全 状态 备份 方案 ， 它 有 多 种 处 理 方 式 ， 比 
如 使 用 Clone 的 方式 就 可 以 解决 ， 使 用 数据 技术 也 可 以 解决 (DTO 回 写 
到 临时 表 中 〉 等 ， 我 们 要 讲 的 方案 束 对 备 态 录 模 式 继续 扩展 一 下 ， 实 现 


一 个 JavaBean 对 象 的 所 有 状态 的 备份 和 还 原 ， 如 图 24-6 所 示 。 













Memento 


| -HashMap<String,Object> stateMap 
+getter/setter() 








+getter/setter() 


-String statel 
-String state2 
-Strmg state3 


+getter/setter() 





+static Hash Map<String,Object> backupProp(Object bean) 
+static void restoreProp(Object bean, HashMap<String, Object> propMap) 





图 24-6 多 状态 的 备 不 录 模 式 


还 是 比较 简单 的 类 图 ， 增 加 了 一 个 BeanUtils 类 ， 其 中 backupProp 是 
把 发 起 人 的 所 有 属性 值 转换 到 HashMap 中 ， 方 便 备忘录 角色 存储 ; 
restoreProp 方 法 则 是 把 HashMap 中 的 值 返回 到 发 起 人 角色 中 。 可 能 各 位 
要 说 了 ， 为 什么 要 使 用 HashMap， 直 接 使 用 Originator 对 象 的 拷贝 不 是 一 
个 很 好 的 方法 吗 ? 可 以 这 样 做 ， 你 就 破坏 了 发 起 人 的 通用 性 ， 你 在 做 恢 
复 动 作 的 时 候 需 要 对 该 对 象 进行 多 次 赋值 操作 ， 也 容易 产生 错误 。 我 们 
先 来 看 发 起 人 和 角色， 如 代码 清单 24-16 所 示 。 


代码 清单 24-16 发 起 人 角色 


public class Originator { 
// 内 部 状态 
private String statel1 
private String state2 
private String state3 


了 
IT。 


IT。 
了 


public String getState1() { 
return statel; 


} 
public void setState1(String state1) { 
this.state1 = statel,; 


} 
public String getState2() { 
return state2; 


public void setState2(String state2) { 
this.state2 = state2; 


} 
public String getState3() { 
return state3; 


} 
public void setState3(String state3) { 
this.state3 = state3; 


} 
// 创 建 一 个 备 态 录 
public Memento createMemento( ){ 
return new Memento(BeanUtils.backupProp(this)); 


} 

// 恢 复 一 个 备 访 录 

public void restoreMemento(Memento _memento)t{ 
BeanUtils.restoreProp(this, _memento.getStateMap()); 











// 增 加 一 个 toString 方 法 
@Override 
public String toString(){ 

return "state1i=" +state1+"\nstat2="+Sstate2+"\nstate3 
} 


履 写 toString 方 法 是 为 了 方便 打印 ， 可 以 让 展示 的 结果 更 清晰 。 我 
们 再 来 看 BeanUtils 工 具 类 ， 如 代码 清单 24-17 所 示 。 


代码 清单 24-17 BeanUtils 工 具 类 


public class BeanUtils { 
// 把 bean 的 所 有 属性 及 数值 放 入 到 Hashmap 中 
public static HashMap<String,Object> backupProp(Object bean) 
HashMap<String,Object> result = new HashMap<String,0 
try { 











// 获 得 Bean 描 述 














BeanInfo beanInfo=Introspector ,getBeanInfo(b 
// 获 得 属性 描述 
PropertyDescriptor[] descriptors=beanInfo ,ge 
// 遍 历 所 有 属性 
for(PropertyDescriptor des:descriptors)t{ 
// 属 性 名 称 
String fieldName = des.getName( ); 
// 读 取 属 性 的 方法 
Method getter = des.getReadMethod () ; 
// 读 取 属 性 值 
Object fieldvValue=getter.invoke(bean 
if(!fieldName.equalsIgnoreCase("class"))t 
result.put(fieldName, fieldValue); 
} 


} 

} catch (Exception e) { 
// 异 常 处 理 

} 


return result,; 
























































} 
// 把 HashMap 的 值 返回 到 bean 中 
public static void restoreProp(Object bean,HashMap<String,ob 
try { 
// 获 得 Bean 描 述 
BeanInfo beanInfo = Introspector.getBeanIinfo(bean. 
// 获 得 属性 描述 
PropertyDescriptor[] descriptors = beanInfo .getPro 
// 遍 历 所 有 属性 
for(PropertyDescriptor des:descriptors)t{ 
// 属 性 名 称 
String fieldName = des.getName( ); 
// 如 果 有 这 个 属性 
if(propMap.containsKkey(fieldName))t 
// 写 属性 的 方法 
Method setter = des.getwriteMethod(); 
setter.invoke(bean, new Object[]{propMap 
























































} 

} catch (Exception e) { 
// 异 常 处 理 
System.out.printlin("shit"); 
e.printStackTrace( ); 























该 类 大 家 在 项 目 中 会 经 常用 到 ， 可 以 作为 参考 使 用 。 类 似 的 功能 
很 多 工具 已 经 提供 ， 比 如 Spring、Apache 工 具 集 commons 等 ， 大 家 也 可 
以 直接 使 用 。 我 们 再 来 看 备忘录 和 角色， 如 代码 清单 24-18 所 示 。 


代码 清单 24-18 备忘录 角色 


public class Memento { 
// 接 受 HashMap 作 为 状态 
private HashMap<String,Object> stateMap; 
// 接 受 一 个 对 象 ， 建 立 一 个 备份 
public Memento(HashMap<String,Object> map)t{ 
this.stateMap = map; 





} 
public HashMap<String,Object> getStateMap() { 
return stateMap; 


public void setStateMap(HashMap<String,Object> stateMap) { 
this.stateMap = stateMap; 
} 


我 们 再 编写 一 个 场景 类 ， 看 看 我 们 的 成 果 是 否 正确 ， 如 代码 清单 
24-19 所 示 。 


代码 清单 24-19 场景 类 


public class Client { 
public static void main(String[] args) { 

// 定 义 出 发 起 人 
Originator ori = new Originator(); 
// 定 义 出 备忘录 管理 员 
Caretaker caretaker = new Caretaker(); 
// 初 始 化 
ori.setState1(" 中 国 " ) ; 
ori.setState2(" 强 盛 " ) ， 
ori.setState3(" 繁 荣 " ) ; 
System.out.printlLn("=== 初 始 化 状态 ===\n"+orI) ; 
// 创 建 一 个 备忘录 
































caretaker ,setMemento(ori,createMemento( ) ) ; 
// 修 改 状 态 值 

ori,setState1(" 软 件 " ) ; 

ori,setState2(" 架 构 " ) ; 

ori,setState3(" 优 秀 " ) ; 
System.out.println("\n=== 修 改 后 状态 ===\n"+ori)， 














// 恢 复 一 个 备忘录 
ori.restoreMemento(caretaker. getMemento( )); 
. System.out.printlin("\n=== 恢 复 后 状态 ===\n"+ori)，; 
运行 结果 如 下 所 示 : 

=== 初 始 化 状态 === 

statel= 中 国 

stat2= 强 盛 

state3= 繁 荣 

=== 修 改 后 状态 === 

state1= 软 件 

stat2= 架 构 

state3= 优 秀 

=== 恢 复 后 状态 === 

state1= 中 国 

stat2= 强 盛 


state3= 繁 荣 


通过 这 种 方式 的 改造 ， 不 管 有 多 少 状 态 都 没有 问题 
一 人 过， 想 恢 复 当 时 的 点 数据 ? 那 太 容易 了 ! 


对 象 所有 属性 都 备份 了 


， 直 接 把 原 有 的 





注意 如果 要 设计 一 个 在 运行 期 决定 备份 状态 的 框架 ， 则 建议 采 


用 AOP 框 架 来 实现 ， 避 免 采 用 动态 代理 无 谓 地 增加 程序 逻辑 复杂 性 。 


24.4.3 多 备份 的 备 环 录 


不 知道 你 有 没有 做 过 系统 级 别 的 维护 ? 比如 Backup 
Administrator〈 备 份 党 理 员 ) ， 每 天 负责 查看 系统 的 备份 情况 ， 所 有 的 
备份 都 是 由 目 动 化 脚本 产生 的 。 有 一 天 ， 突 然 有 一 个 重要 的 系统 说 我 数 
据 库 有 扣 问 题 ， 请 把 上 一 个 月 末 的 数据 拉 出 来 恢复 ， 那 怎么 办 ?对 备份 
管理 员 来 说 ， 这 很 好 办 ， 直 接 根 据 时 间 惟 找到 这 个 备份 ， 还 原 回去 就 成 
了 ， 但 是 对 于 我 们 刚刚 学 习 的 备 坊 录 模 式 却 行 不 通 ， 为 什么 呢 ? 它 对 于 
一 个 确定 的 发 起 人 ， 永 远 只 有 一 份 备 份 ， 在 这 种 情况 下 ， 单 一 的 备份 就 
不 能 满足 要 求 了 ， 我 们 需要 设计 一 套 多 备份 的 架构 。 











我 们 先 来 说 一 个 名 词 ， 检 查 点 〈Check Point) ， 也 就 是 你 在 备份 的 
时 候 做 的 戳记 ， 系 统 级 的 备份 一 般 是 时 间 戳 ， 那 我 们 程序 的 检查 点 该 怎 


么 设计 呢 ? 一 般 是 一 个 有 意义 的 字符 串 。 





我 们 只 要 把 通用 代码 中 的 Caretaker 管 理 员 稍 做 修改 就 可 以 了 ， 如 代 
码 清 单 24-20 所 示 。 


代码 清单 24-20 备忘录 管理 员 


public class Caretaker { 
// 容 纳 备忘录 的 容器 
private HashMap<String,Memento> memMap = new HashMap<String, 
public Memento getMemento(String idx) { 
return memMap.get(idx); 


public void setMemento(String idx,Memento memento) { 
this.memMap.put(idx, memento); 
} 





把 容纳 备忘录 的 容器 修改 为 Map 类 型 就 可 以 了 ,场景 类 也 稍 做 改 
动 ， 如 代码 清单 24-21 所 示 。 


代码 清单 24-21 场景 类 


public class Client { 
public static void main(String[] args) { 











// 定 义 出 发 起 人 

Originator originator = new Originator(); 
// 定 义 出 备忘录 管理 员 

Caretaker caretaker = new Caretaker(); 
// 创 建 两 个 备 态 录 





caretaker.setMemento("001",originator.createMemento( 
caretaker.setMemento("002",originator.createMemento( 
// 恢 复 一 个 指定 标记 的 备忘录 


originator.restoreMemento(caretaker .getMemento( "001" 








注意 内存 溢出 问题 ， 该 备份 一 旦 产生 就 装 入 内 存 ， 没 有 任何 销 
毁 的 意 癌 ， 这 是 非常 危险 的 。 因 此 ， 在 系统 设计 时 ， 要 严格 限定 备 坏 录 
的 创建 ， 建 议 增 加 Map 的 上 限 ， 人 否则 系统 很 容易 产生 内 存 洪 出 情况 。 











24.4.4 封装 得 更 好 一 点 


在 系统 管理 上 ， 一 个 备份 的 数据 是 完全 、 绝 对 不 能 修改 的 ， 它 保证 
数据 的 活 奖 ， 避 免 数 据 污 染 而 使 备份 失去 意义 。 在 我 们 的 设计 领域 中 ， 
也 存在 着 同样 的 问题 ， 备 份 是 不 能 家 纂 改 的 ， 也 区 是 说 需要 缩小 备份 出 
的 备 瑟 录 的 阅读 权限 ， 保 证 只 能 是 发 起 人 可 读 就 成 了 ， 那 怎么 才能 做 到 

一 点 昵 ?使 用 内 置 类 ， 如 图 24-7 所 示 。 


: 
<<interface>> 
Le IMemento 


-String state 
= 
Eo 





-IMemento memento 














+getter/setter() 


+getter/setter() 
+ Memento create Memento() 
+void restoreMemento(IMemento memento) 






-String getState() 
-void setState(String state) 


图 24-7 使 用 内 置 类 的 备 未 录 模 式 





这 也 是 比较 简单 的 ， 建 立 一 个 空 接口 IMemento 什么 方法 属性 都 
没有 的 接口 ， 然 后 在 发 起 人 Originator 类 中 建立 一 个 内 置 类 〈 也 叫做 类 中 
类 ) Memento 实 现 IMemento 接 口 ， 同 时 也 实现 上 自己 的 业务 逻辑 ， 如 代码 


清单 24-22 所 示 O 


代码 清单 24-22 发 起 人 角色 


public class Originator { 
// 内 部 状态 
private String state = ""; 
public String getstatef) { 


return State， 


} 
public void setState(String state) { 
this.state = state,; 


} 
// 创 建 一 个 备 态 录 
public IMemento createMemento( ){ 
return new Memento(this.state); 


} 

// 恢 复 一 个 备忘录 

public void restoreMemento(IMemento _memento ){ 
this.setState(((Memento) memento).getSstate()); 





} 
// 内 置 类 
private class Memento implements IMementot 
// 发 起 人 的 内 部 状态 
private String state = ""; 
// 构 造 函 数 传递 参数 
private Memento(String _state)t{ 


this.state = _state; 


private String getState() { 
return state; 
} 


private void setState(String state) { 
this.state = state,; 
} 


OR ti te gn 


外 ， 别 人 休想 访问 到 ， 那 如 果 要 产生 关联 关系 又 应 如 何 处 理 呢 ? 
别 筷 记 了 我 们 还 有 一 个 空 接口 是 公共 的 访问 权限 ， 如 代码 清单 24- 
23 所 示 。 


代码 清单 24-23 备忘录 的 空 接口 


public interface IMemento { 


过 接 


我 们 再 来 看 管理 者 ， 如 代码 清单 24-24 所 示 。 


代码 清单 24-24 备忘录 管理 者 


public class Caretaker { 
// 和 备忘录 对 象 
private IMemento memento; 
public IMemento getMemento() { 
return memento; 


public void setMemento(IMemento memento) { 
this.memento = memento; 
} 


全 部 通过 接口 访问 ， 这 当然 没有 问题 ， 如 果 你 想 访 问 它 的 属性 那 是 
肯定 不 行 的 。 但 是 安全 是 相对 的 ， 没 有 绝对 的 安全 ， 可 以 使 用 refelect 反 
射 修改 Memento 的 数据 。 





在 这 里 我 们 使 用 了 一 个 新 的 设计 方法 : 双 接 口 设计 ， 我 们 的 一 个 类 
可 以 实现 多 个 接口 ， 在 系统 设计 时 ， 如 果 考 虑 对 象 的 安全 问题 ， 则 可 以 
提供 两 个 接口 ， 一 个 是 业务 的 正常 接口 ， 实 现 必要 的 业务 逻辑 ， 叫 做 宽 
接口 ， 另 外 一 个 接口 是 一 个 空 接 口 ， 什 么 方法 都 没有 ， 其 目的 是 提供 给 
子 系统 外 的 模块 访问 ， 比 如 容器 对 象 ， 这 个 叫做 罕 接 口 ， 由 于 窜 接 口中 
没有 提供 任何 操纵 数据 的 方法 ， 因 此 相对 来 说 比较 安全 。 





24.5 最 佳 实践 


备 捷 录 模 式 是 我 们 设计 上 “月 光宇 盒 ”” 可 以 让 我 们 回 到 需要 的 年 
代 ; 是 程序 数据 的 “后 悔 药 ”， 吃 了 它 就 可 以 返回 上 一 个 状态 是 设计 人 
员 的 定心丸 ， 确 保 即 使 在 最 坏 的 情况 下 也 能 获得 最 近 的 对 象 状态 。 如 末 
大 家 看 懂 了 的 话 ， 请 各 位 在 设计 的 时 候 就 不 要 使 用 数据 库 的 临时 表 作 为 
绥 存 备份 数据 了 ， 虽 然 是 一 个 简单 的 办 法 ， 但 是 它 加 大 了 数据 库 操作 的 
频繁 度 ， 把 压力 下 放 到 数据 库 了 ， 最 好 的 解决 办 法 就 是 使 用 备忘录 模 
式 。 








第 25 章 访问 者 模式 


25.1 员工 的 隐私 何在 


我 们 在 前 面 讲 过 了 组 合 模式 和 迭代 器 模式 。 通 过 组 合 模式 能 够 把 一 
个 公司 的 人 员 组 织 机 构 树 搭建 起 来 ， 给 管理 带 来 非常 大 的 便利 ， 通 过 从 
代 絮 模式 把 每 一 个 员工 都 志 历 一 壳 ， 看 看 是 不 是 “有 人 去 世 了 还 在 领 退 
休 人 金 ”，“ 拿 高 工资 而 不 干 活 的 性 位 素 餐 ”等 情况 ， 我 们 今天 要 做 的 就 是 
把 这 些 情况 统计 成 一 个 报表 呈报 上 去 ， 让 领导 看 看 这 种 恶劣 的 情况 有 多 
严重 。 














我 们 公司 有 700 名 多 技术 人 员 ， 分 布 在 全 国 各 地 ， 组 织 架 构 在 组 合 
模式 中 己 经 介绍 过 了 ， 是 很 常见 的 家 长 领导 型 模式 ， 每 个 技术 人 员 的 岗 
位 都 是 固定 的 ， 你 在 组 织 机 构 的 哪 棵 树 下 ， 充 当 的 角色 是 什么 ， 叶 子 节 
所 部 是 非常 明确 的 ， 每 一 个 员工 的 信息 (如 名 字 、 性 别 、 薪 水 等 都 是 
记录 在 数据 库 中 ， 现 在 有 这 样 一 个 需求 ， 我 要 把 公司 中 的 所 有 人 员 信 息 
都 打印 汇报 上 去 。 我 们 来 看 类 图 ， 如 图 25-1 所 示 。 





Employee 


-nt salary 


-String name a 
Client ex 抽象 员工 


+getter/setter salary() 
+getter/setter name() 
+getter/setter sex() 
+vold report() 

#String getOtherInfol) 











CommonEmployee 





-String job 


+getter/setter job() 


a a 
管理 层 人 员 


图 25-1 员工 信息 类 图 





这 个 类 图 还 是 比较 简单 的 ， 我 们 定义 每 个 员工 部 有 薪水 salary、 名 
称 name、 性 别 sex 这 3 个 属性 ， 然 后 提供 了 一 个 抽象 方法 getOtherInfo 由 子 
类 进行 扩展 ， 同 时 通过 report 方 法 打印 出 每 一 个 员工 的 信息 ， 这 里 使 用 
模板 方法 模式 。 我 们 先 来 看 一 下 抽象 类 ， 如 代码 清单 25-1 所 示 。 








代码 清单 25-1 抽象 员工 


public abstract class Employee { 
public final static int MALE = 
public final static int FEMALE 
// 逢 管 是 谁 ， 都 有 工资 














0; //0 代 表 是 男性 
= 1; //1 代 表 是 女性 





private String name; 
// 只 要 是 员工 那 就 有 薪水 

private int salary; 

// 性 别 很 重要 
private int sex; 

// 以 下 是 简单 的 getter/setter 
public String getName() { 

return name; 

















public void setName(String name) { 
this.name = name; 


} 
public int getSalary() { 
return salary; 


public void setSalary(int salary) { 
this.salary = salary; 


} 
public int getSex() { 
return sex; 


public void setSex(int sex) { 
this.sex = sex; 


} 
// 打 印 出 员工 的 信息 
public final void report()t{ 








String info = "姓名 : " + this.name + "\t"; 


info = info + "性 别 : " + (this.sex 





== FEMALE?" 女 ":" 


info = info + "薪水 : " + this.salary + "\t"; 





// 获 得 员工 的 其 他 信息 





info = info + this.getotherIinfo(); 


System.out.println(info); 


3 
// 拼 装 员工 的 其 他 信息 





protected abstract String getotherInfo( ) ; 





的 经 历 、 思 维和 闫 难 。 请 看 实现 类 ， 如 代码 清单 25-2 所 示 。 


代码 清单 25-2 普通 员工 


public class CommonEmployee extends Employee { 








// 工 作 内 容 ， 这 非常 重要 ， 以 后 的 职业 规划 就 是 








靠 它 了 

















先 看 小 兵 的 实现 类 ， 越 插 微 的 人 物 越 能 引起 共鸣 ， 因 为 我 们 有 共同 


private String job; 
public String getJob() { 
return job; 


} 
public void setJob(String job) { 
this.job = job; 


} 
protected String getotherInfo(){ 

return "工作 : "+ this.job + "\t"; 
} 





每 个 实现 类 都 必须 实现 getOtherInfo 信 息 ， 通 过 它 获 得 用 户 个 性 信 
上 县， 我 们 再 来 看 管理 阶层 ， 如 代码 清单 25-3 所 示 。 


代码 清单 25-3 管理 阶层 


public class Manager extends Employee { 
// 这 类 人 物 的 职责 非常 明确 业绩 
private String performance,; 
public String getPerformance() { 
return performance; 

















public void setPerformance(String performance) { 
this.performance = performance; 


} 
protected String getotherInfo(){ 

return "业绩 : "+ this.performance + "\t"，; 
} 


Performance 这 个 单词 在 技术 人 员 的 眼 里 就 代表 性 能 ， 在 实际 商务 英 
语 中 可 以 有 Sales Performance (销售 业绩 ) 、performance evaluation ( 业 
绩 评估 〉 等 。 系 统 的 框架 都 已 经 具备 了 ， 那 我 们 来 模拟 一 下 这 个 过 程 ， 
如 代码 清单 25-4 所 示 。 


代码 清单 25-4 场景 类 


public class Client { 


public static void main(String[] args) { 


for(Employee emp:mockEmployee())t{ 
emp.report(); 
} 





} 
// 模 拟 出 公司 的 人 员 情 况 ， 我 们 可 以 想象 这 个 数据 是 通过 持久 层 传递 过 来 的 
public static List<Employee> mockEmployee(){ 





List<Employee> empList = new ArrayList<Employee>(); 
// 产 生 张 三 这 个 员工 

CommonEmployee zhangSan = new CommonEmployee(); 
zhangSan.setJob(" 编 写 Java 程 序 ， 绝 对 的 蓝领 、 苦 工 加 搬运 工 " ) ， 
zhangSan.setName(" 张 三 ")， 

zhangSan.setSalary(1800); 
zhangSan.setSex(Employee .MALE); 
empList.add(zhangSsan); 

// 产 生 李 四 这 个 员工 

CommonEmployee 1iSi = new CommonEmployee(); 
1iSi.setJob(" 页 面 美工 ， 审 美 素质 太 不 流行 了 ! "); 
1iSi,setName(" 李 四 ") ， 

1iSi.setSalary(1900); 

1iSi.setSex(Employee.FEMALE); 

empList.add(1iSi); 

// 再 产生 一 个 经 理 
Manager wangwu = new Manager(); 

wangwu .setName(" 王 五 ")，; 

wangwu.setPerformance(" 基 本 上 是 负 值 ， 但 是 我 会 拍马屁 呀 ")， 
wangWu.setSalary(18750); 
wangWu.setSex(Employee .MALE); 

empList.add(wangWu)，; 

return empList; 


















































先 通 过 mockEmployee 来 模拟 出 一 个 数组 ， 初 始 化 两 个 员工 和 一 个 
经 理 ， 当 然 在 实际 项 目 中 这 个 数组 应 该 由 持久 层 产 生 。 运 行 结果 如 下 所 





薪水 : 工作 : 编写 Java 程 序 ， 绝 对 的 蓝领 、 


男 1800 兰 工 加 搬运 工 


薪水 : 工作 : 页 面 美工 ， 审 美 素质 太 不 流行 


别 : 女 1900 TT 





姓名 : 性 薪水 : 业绩 : 基本 上 是 负 值 ， 但 是 我 会 拍 马 
王 五 “ 别 : 男 18750 屁 呀 

结果 出 来 了 ， 非 常 正确 。 我 们 来 想 一 想 实际 的 情况 ， 人 力 资源 部 门 
拿 这 份 表格 会 给 谁 看 呢 ? 那 当然 是 大 老板 了 ! 大 老板 关心 的 是 什么 ? 关 
心 部 门 经 理 的 业绩 ! 小 兵 的 情况 不 是 他 要 了 解 的 ， 就 像 成 争 时 期 一 位 将 
军 说 : “我 一 想到 我 的 士兵 也 有 孩子、 妻子 、 父 母 ， 我 就 痛心 疾 首 .………. 
但 是 这 是 战场 ， 我 只 能 认为 他 们 是 一 群 机 器 .……” 是 啊 ， 其 实 我 们 也 一 
样 啊 ， 那 问题 就 出 来 了 : 








e 大 老板 就 看 部 门 经 理 的 报表 ， 小 兵 的 报表 可 看 可 不 看 。 


e 多 个 大 老板 的 “嗜好 ”是 不 同 的 ， 主 省 销售 的 ， 则 主要 关心 营销 的 
情况 ， 主 管 会 计 的 ， 则 主要 关心 企业 的 整体 财务 运行 状态 ， 主 管 技术 
的 ， 则 主要 看 技术 的 研发 情况 。 


综合 成 一 句 话 ， 这 个 报表 会 修改 : 数据 的 修改 以 及 报表 的 展现 修 
改 ， 按 照 开 闭 原则 ， 项 目 分 析 的 时 候 已 经 考虑 到 这 些 可 能 引起 变更 的 因 
素 ， 就 需要 在 设计 时 考虑 通过 扩展 来 避 开 未 来 需求 变更 而 引起 的 代码 修 
改 风险 。 我 们 来 想 一 想 ， 每 个 普通 员工 类 和 经 理 类 都 用 一 个 方法 
report〈 从 父 类 继承 过 来 的 ) ， 他 无 法 为 每 一 个 子 类 定制 特殊 的 属性 ， 
简化 类 图 如 图 25-2 所 示 。 













Employee 


+Vold report() 


i 


CommonEmployee 


图 25-2 简化 类 图 


我 们 思考 一 下 ， 如 何 提供 一 个 能 够 为 每 个 子 类 定制 报表 的 方法 呢 ? 
可 以 这 样 思 考 ， 普 通 员工 和 管理 层 员工 是 两 个 不 同 的 对 象 ， 例 如 ， 我 邀 
请 一 个 人 过 来 参观 我 的 家 ， 参 观 者 参观 完毕 后 分 别 进行 描述 ， 那 参观 的 
对 象 不 同 ， 描 述 的 结果 也 当然 不 同 。 好 ， 按 照 这 思路 ， 我 们 把 方法 
report 提 取 到 另外 一 个 类 Visitor 中 来 实现 ， 如 图 25-3 所 示 。 











CommonEmployee 


Visitor 


+Vold report() 





图 25-3 改造 后 的 简化 类 图 





两 个 子 类 的 report 方 法 都 不 需要 了 ， 只 有 Visitor 类 来 实现 了 report 的 
方法 ， 这 个 猛 一 看 还 真有 点 委托 〈intergration) 的 意味 ， 我 们 实现 出 来 
你 就 知道 这 和 委托 有 非常 大 的 差距 。 详 细 类 图 如 图 25-4 所 示 。 








<<interface>> 






TVisitor 
Client 


itVISit(CommonEmployee commonEmployee) 
ftVoid visit(Manager manager) 






i | 
访问 者 Visitor 
Employee 


-int salary 
-String name 
-int SeX 


rgetter/setter salary() 
rgetter/setter name() 
tgetter/setter sex() 

+vold report() 

tvoid accept(IVisitor visitor) 






CommonEmployee 


-Strng pertormance 






-String job 


+getter/setter job() +getter/setter performance() 


图 25-4 改造 后 的 详细 类 图 


在 抽象 类 Employee 中 增加 了 accept 方 法 ， 该 方法 是 一 个 抽象 方法 ， 
由 子 类 实现 ， 其 意义 就 是 说 我 这 个 类 可 以 允许 谁 来 访问 ， 也 就 是 定义 一 
类 访问 者 ， 在 具体 的 实现 类 中 调用 访问 者 的 方法 。 我 们 先 看 访问 者 接口 
IVisitor 程 序 ， 如 代码 清单 25-5 所 示 。 


代码 清单 25-5 访问 者 接口 


public interface IVisitor t 
// 首 先 ， 定 义 我 可 以 访问 普通 员工 
public void visit(CommonEmployee commonEmployee); 
// 其 次 ， 定 义 我 还 可 以 访问 部 门 经 理 
public void visit(Manager manager ) ; 



































该 接口 的 意义 是 : 该 接口 可 以 访问 两 个 对 象 ， 一 个 是 普通 员工 ， 一 
个 是 高 层 员工 。 我 们 来 看 其 具体 实现 类 ， 如 代码 清单 25-6 所 示 。 





代码 清单 25-6 访问 者 实现 


public class Visitor Implements IVisitor { 
// 访 问 普 通 员 工 ， 打 印 出 报表 
public void visit(CommonEmployee commonEmployee) { 
System.out.println(this.getCommonEmployee(commonEmpl 

















} 

// 访 问 部 门 经 理 ， 打 印 出 报表 

public void visit(Manager manager) { 
System.out.println(this.getManagerIinfo(manager)); 


} 

// 组 装 出 基本 信息 

private String getBasicIinfo(Employee employee)t{ 
String info = "姓名 : " + employee.getName() + "\t"; 
info = info + "性 别 : " + (employee.getSex() == Employ 
info = info + "薪水 : " + employee.getSalary() + "\t" 
return Info ， 


} 
// 组 装 出 部 门 经 理 的 信息 
private String getManagerInfo(Manager manager ){ 
String basicInfo = this.getBasicIinfo(manager ) ; 
String otherInfo = "业绩 : "+manager ,getPerformance( ) 
return basicInfo + otherInfo 












































} 

// 组 装 出 普通 员工 信息 

private String getCommonEmployee(CommonEmployee commonEmploy 
String basicInfo = this.getBasicIinfo(commonEmployee) 
String otherInfo = "工作 : "+commonEmployee.getJob()+" 
return basicInfo + otherInfo ， 





在 具体 的 实现 类 中 ， 定 义 了 两 个 私有 方法 ， 作 用 就 是 产生 需要 打印 
的 数据 和 格式 ， 然 后 在 访问 者 访问 相关 的 对 象 时 产生 这 个 报表 。 抽 象 员 
工 Employee 稍 有 修改 ， 如 代码 清单 25-7 所 示 。 


代码 清单 25-7 抽象 员工 类 


public abstract class Employee { 


public 
public 

















final static int MALE = 0; //0 代 表 是 男性 
final static int FEMALE = 1; //1 代 表 是 女性 


// 第 管 是 谁 ， 都 有 工资 


private String name; 

















// 只 要 是 员工 那 就 有 薪水 
private int salary; 


// 性 别 很 重要 











private int sex; 
// 以 下 是 简单 的 getter/setter 


public 
} 
public 
} 
public 
} 
public 
} 
public 


} 
public 


String getName() { 
return name; 


void setName(String name) { 
this.name = name; 


int getSalary() { 
return salary; 


void setSalary(int salary) { 
this.salary = salary; 


int getSex() { 
return sex; 


void setSex(int sex) { 
this.sex = sex; 


} 
// 我 允许 一 个 访问 者 访问 


public 





abstract void accept(IVisitor visitor); 





抽象 员工 类 有 3 个 变动 : 


e 删除 了 report 方 法 。 
e@ 增加 了 accept 方 法 ， 接 受 访问 者 的 访问 。 


e 删除 了 getOtherInfo 方 法 。 它 的 实现 由 访问 者 来 处 理 ， 因 为 访问 者 
对 被 访问 的 对 象 是 " 心 知 肚 明 ”的 ， 非 常 了 解 被 访问 者 。 


我 们 继续 来 看 员工 实现 类 ， 普 通 员工 代码 清单 25-8 所 示 。 


代码 清单 25-8 普通 员工 


public class CommonEmployee extends Employee { 
// 工 作 内 容 ， 这 非常 重要 ， 以 后 的 职业 规划 就 是 靠 它 了 
private String job; 
public String getJob() { 
return job; 











} 
public void setJob(String job) { 
this.job = job; 


} 

// 我 允许 访问 者 访问 

@Override 

public void accept(IVisitor visitor)t{ 
visitor.visit(this); 





上 面 是 普通 员工 的 实现 类 ， 该 类 的 accept 方 法 很 简单 ， 这 个 类 就 把 
自身 传递 过 去 ， 也 就 是 让 访问 者 访问 本 身 这 个 对 象 。 再 看 Manager 类 ， 
如 代码 清单 25-9 所 示 。 





代码 清单 25-9 管理 层 员工 


public class Manager extends Employee { 








// 这 类 人 物 的 职员 非 第 明确 : 业绩 

private String performance ; 

public String getPerformance() { 
return performance; 











public void setPerformance(String performance) { 
this.performance = performance; 























} 

// 部 门 经 理 允 许 访问 者 访问 

@Override 

public void accept(IVisitor visitor)t{ 
visitor.visit(this); 

} 








所 有 的 业务 定义 都 已 经 完成 ， 我 们 来 看 看 怎么 模拟 这 个 逻辑 ， 如 代 
码 清 单 25-10 所 示 。 


代码 清单 25-10 场景 类 


public class Client { 
public static void main(String[|] args) { 
for(Employee emp:mockEmployee())t{ 
emp.accept(new Visitor()) 
} 


} 
// 模 拟 出 公司 的 人 员 情 况 ， 我 们 可 以 想象 这 个 数据 是 通过 持久 层 传递 过 来 的 
public static List<Employee> mockEmployee(){ 
List<Employee> empList = new ArrayList<Employee>(); 
// 产 生 张 三 这 个 员工 
CommonEmployee zhangSan = new CommonEmployee(); 
zhangSan.setJob(" 编 写 Java 程 序 ， 绝 对 的 蓝领 、 苦 工 加 搬运 工 " ) ， 
zhangSan.setName(" 张 三 ")， 
zhangSan.setSalary(1800); 
zhangSan.setSex(Employee .MALE); 
empList.add(zhangSsan); 
// 产 生 李 四 这 个 员工 
CommonEmployee 1iSi = new CommonEmployee(); 
1iSi.,setJob( "页面 美工 ， 审 美 素质 太 不 流行 了 ! "); 
lisi,.setName(" 李 四 ")，; 
1iSi.setSalary(1900); 
1iSi.setSex(Employee.FEMALE); 
empList.add(1iSi); 
// 再 产生 一 个 经 理 


了 












































改动 非 闻 


姓名 : 


纹 三 ，' 节 |; 


姓名 : 


李 四 ”” 别 : 


姓名 : 
平手 


: 男 18750 


Manager wangwu = new Manager(); 
wangwu .setName(" 王 五 ") ; 

wangwu.setPerformance(" 基 本 上 是 负 值 ， 但 是 我 会 拍马屁 呀 ")， 
wangWu.setSalary(18750); 
wangWu.setSex(Employee .MALE); 

empList.add(wangwu ) ; 

return empList， 














少 ， 就 黑体 那么 一 行 的 改动 ， 运 行 结果 如 下 : 

工作 : 编写 Java 程 序 ， 绝 对 的 蓝领 、 
昔 工 加 搬运 工 

J ies Ma 
了 1 


薪水 : 
1800 

薪水 : 
1900 

薪水 : 业绩 
屁 呀 


审美 素质 太 不 流行 





: 基本 上 是 负 值 ， 但 是 我 会 拍 马 


通过 循环 刀 历 所 有 元 素 。 





每 个 员工 对 象 都 定义 了 一 个 访问 者 。 


员工 对 象 把 目 己 作为 一 个 参数 调用 访问 者 visit 方 法 。 


访问 者 调用 自己 内 部 的 计算 逻辑 ， 计 算出 相应 的 数据 和 表 


访问 者 打印 出 报表 和 数据 。 


经 过 就 是 这 个 样子 。 那 我 们 再 来 看 看 上 面 提 到 的 数据 和 报表 


格式 都 会 改变 的 情况 。 首 先是 数据 的 改变 ， 数 据 改 了 当然 都 要 改 ， 说 不 
上 两 个 方案 有 什么 优 务 ;， 其 次 是 报表 格式 的 修改 ， 这 个 方案 绝对 是 有 优 
势 的 ， 我 只 要 再 产生 一 个 IVisitor 的 实现 类 就 可 以 产生 一 个 新 的 报表 格 
式 ， 而 其 他 的 类 都 不 用 修改 ， 如 果 你 用 Spring 开 肥 ， 那 残 更 好 了 ， 在 
Spring 的 配置 文件 中 使 用 的 是 接口 注入 ， 我 只 要 把 配置 文件 中 的 ref 修 改 
一 下 就 行 了 ， 其 他 的 都 不 用 修改 了 ! 这 就 是 访问 者 模式 的 优势 所 在 。 








25.2 访问 者 模式 的 定义 


访问 者 模式 〈Visitor Pattern ) 是 一 个 相对 简单 的 模式 ， 其 定义 如 
下 : Represent an operation to be performed on the elements of an object 
structure. Visitor lets you define a new operation without changing the 
classes of the elements on which it operates. (封装 一 些 作用 于 某 种 数据 结 
构 中 的 各 元 素 的 操作 ， 它 可 以 在 不 改变 数据 结构 的 前 提 下 定义 作用 于 这 
些 元 素 的 新 的 操作 。) 


访问 者 模式 的 通用 类 图 如 图 25-5 所 示 。 





+VisitConcreateElement(elem: ConcreateElement) 


Concrete Visitor 





















ObjectStruture 






ConcreateElement 


| 
== 
图 25-5 访问 者 模式 的 通用 类 图 


看 了 这 个 通用 类 图 ， 大 家 可 能 要 犯 迷 糊 了 ， 这 里 怎么 有 一 个 
ObjectStruture 类 呢 ? 你 刚刚 举 的 例子 怎么 就 没有 了 昵 ? 真 没有 吗 ? 我 们 不 
是 定义 了 一 个 List 了 吗 ? 它 中 间 的 元 素 是 我 们 一 个 一 个 手动 增加 上 去 
的 ， 这 就 是 一 个 ObjectStruture， 我 们 来 看 这 几 个 角色 的 职责 。 


@ Visitor 


抽象 访问 者 








抽象 类 或 者 接口 ， 声 明 访 问 者 可 以 访问 哪些 元 素 ， 具 体 到 程序 中 束 
古 visit 方 法 的 参数 定义 哪些 对 象 是 可 以 被 访问 的 。 





具体 访问 者 


@ ConcreteVisitor 








它 影 啊 访问 者 访问 到 一 个 类 后 该 怎么 干 ， 要 做 什么 事情 。 


抽象 元 系 


© Element 





接口 或 者 抽象 类 ， 声 明 接 受 哪 一 类 访问 者 访问 ， 程 序 上 是 通过 
accept 方 法 中 的 参数 来 定义 的 。 


其 体 元 系 


@ ConcreteElement 





实现 accept 方 法 ， 通 常 是 visitor.visit(this)， 基 本 上 都 形成 了 一 种 模式 


结构 对 象 


® ObjectStruture 








元 素 产 生 者 ， 一 般 容纳 在 多 个 不 同类 、 不 同 接 口 的 容器 ， 如 List、 
Set、Map 等 ， 在 项 目 中 ， 一 般 很 少 抽象 出 这 个 角色 。 


大 家 可 以 这 样 理解 访问 者 模式 ， 我 作为 一 个 访客 (Visitor) 到 朋友 
家 (Visited Class〉 去 拜访 ， 朋 友之 间 聊 聊天 ， 喝 喝酒 ， 再 相互 吹捧 吹 
捧 ， 炫 次 炫 兽 ， 这 都 正常 。 聊 天 的 时 候 ， 朋 友 告 诉 我 ， 他 今年 加 官 晋 狠 
了 ， 工 资 也 涨 了 30%， 准 备 再 买 套 房子 ， 那 我 就 在 心里 盘算 《Visitor- 
self-method)“ 你 这 么 有 钱 ， 我 去 年 要 借 10 万 你 都 不 借 ”"， 我 根据 朋友 的 
信息 ,执行 了 自己 的 一 个 方法 。 


我 们 来 看 看 访问 者 模式 的 通用 源码 ， 先 看 抽象 元 素 ， 如 代码 清单 
25-11 所 示 。 


代码 清单 25-11 抽象 元 素 


public abstract class Element { 
// 定 义 业务 逻辑 
public abstract void doSomething(); 
// 人 允许 谁 来 访问 
public abstract void accept(IVisitor visitor); 























抽象 元 素 有 两 类 方法 : 一 是 本 身 的 业务 逻辑 ， 也 就 是 元 素 作 为 一 个 
业务 处 理 单元 必须 完成 的 职责 ; 另外 一 个 是 允许 哪 一 个 访问 者 来 访问 。 
我 们 来 看 具体 元 素 ， 如 代码 清单 25-12 所 示 。 


代码 清单 25-12 具体 元 素 


public class ConcreteElement1 extends Element{ 
// 完 善 业 务 逻 辑 
public void doSomething(){ 
// 业 务 处 理 


} 

// 人 允许 那个 访问 者 访问 

public void accept(IVisitor visitor)t{ 
visitor.visit(this); 

} 


public class ConcreteElement2 extends Element{ 
// 完 善 业 务 逻 加 
public void doSomething(){ 
// 业 务 处 理 






























































} 

// 人 允许 那个 访问 者 访问 

public void accept(IVisitor visitor)t{ 
visitor.visit(this); 

} 





它 定 义 了 两 个 具体 元 素 ， 我 们 再 来 看 抽象 访问 者 ， 一 般 是 有 几 个 具 
体 元 双 束 有 几 个 访问 方法 ， 如 代码 清单 25-13 所 示 。 


代码 清单 25-13 抽象 访问 者 


public interface IVisitor { 
// 可 以 访问 哪些 对 象 
public void visit(ConcreteElement1 el1); 
public void visit(ConcreteElement2 el12); 


具体 访问 者 如 代码 清单 25-14 所 示 。 


代码 清单 25-14 具体 访问 者 


public class Visitor implements IVisitor { 

// 访 问 eL1 元 素 

public void visit(ConcreteElement1 el1) { 
el1i.doSsomething(); 








} 

// 访 问 e12 元 素 

public void visit(ConcreteElement2 el2) { 
el2.doSomething(); 

} 











结构 对 象 是 产生 出 不 同 的 元 素 对 象 ， 我 们 使 用 工厂 方法 模式 来 模 
拟 ， 如 代码 清单 25-15 所 示 。 


代码 清单 25-15 结构 对 象 


public class ObjectStruture { 
// 对 象 生成 器 ， 这 里 通过 一 个 工厂 方法 模式 模拟 
public static Element createElement(){ 
Random rand = new Random( ) ; 
if(rand.nextInt(100) > 50){ 
return new ConcreteElement1(); 





}elsef{ 
return new ConcreteElement2(); 
} 





进入 了 访问 者 角色 后 ， 我 们 对 所 有 的 具体 元 素 的 访问 就 非常 简单 
了 ， 我 们 通过 一 个 场景 类 模拟 这 种 情况 ， 如 代码 清单 25-16 所 示 。 


代码 清单 25-16 场景 类 


public class Client { 
public static void main(String[] args) { 
for(int i=0;i<10;i++){ 
// 获 得 元 素 对 象 
Element el = ObjectStruture.createElement(); 
// 接 受 访问 者 访问 
el.accept(new Visitor()); 

















通过 增加 访问 者 ， 只 要 是 有 具体 元 素 就 非常 容易 访问 ， 对 元 素 的 明 历 
就 更 加 容易 了 ， 胡 管 它 是 什么 对 象 ， 只 要 它 在 一 个 容器 中 ， 都 可 以 通过 
访问 者 来 访问 ， 任 务 集中 化 。 这 惑 是 访问 者 模式 。 


25.3 访问 者 模式 的 应 用 


25.3.1 访问 者 模式 的 优点 





具体 元 素 角 色 也 就 是 Employee 抽 象 类 的 两 个 子 类 负责 数据 的 加 载 ， 
而 Visitor 关 则 负责 报表 的 展现 ， 两 个 不 同 的 职 贡 非常 明确 地 分 离开 来 ， 
各 目 演 绎 变化 。 





e 优秀 的 扩展 性 


由 于 职责 分 开 ， 继 续 增 加 对 数据 的 操作 是 非常 快捷 的 ， 例 如 ， 现 在 
要 增加 一 份 给 大 老板 的 报表 ， 这 份 报表 格式 又 有 所 不 同 ， 直 接 在 Visitor 
中 增加 一 个 方法 ， 传 递 数 据 后 进行 整理 打印 。 


e 灵活 性 非常 高 


例如 ， 数 据 汇 总 ， 就 以 刚刚 我 们 说 的 Employee 的 例子 ， 如 果 我 现在 
要 统计 所 有 员工 的 工资 之 和 ， 怎 么 计算 ? 把 所 有 人 的 工资 for 循 环 加 一 
裔 ? 是 个 办 法 ， 那 我 再 提 个 问题 ， 员 工 工资 x1.2， 部 门 经 理 x1.4， 总 经 
理 x1.8， 然 后 把 这 些 工资 加 起 来 ， 你 怎么 处 理 ? 1.2，1.4，1.8 是 什么 ? 
不 是 吧 ? ! 你 没 看 到 领导 不 论 什 么 时 候 都 比 你 拿 得 多 ， 工 资 奖 金 就 不 说 


了 ， 就 是 过 节 发 个 慰问 券 也 比 你 多 ， 束 是 这 个 系数 在 作 深 。 我 们 继续 说 
你 想 怎么 统计 ? 使 用 for 循 环 ， 然 后 使 用 instanceof 来 判断 是 员工 还 是 经 
理 ? 这 可 以 解决 ， 但 不 是 个 好 办 法 ， 好 办 法 是 通过 访问 者 模式 来 实现 ， 
把 数据 扔 给 访问 者 ， 由 访问 者 来 进行 统计 计算 。 


25.3.2 访问 者 模式 的 缺点 





e 具体 元 素 对 访问 者 公布 细 市 





访问 者 要 访问 一 个 类 就 必然 要 求 这 个 类 公布 一 些 方法 和 数据 ， 也 就 
征 说 访问 者 关注 了 其 他 关 的 内 部 细节 ， 这 是 迪 米 特 法 则 所 不 建议 的 。 








e 具体 元 条 变更 比较 困难 


具体 元 素 角 色 的 增加 、 删 除 、 修 改 都 是 比较 困难 的 ， 就 上 面 那 个 例 
子 ， 你 想 想 ， 你 要 是 想 增 加 一 个 成 员 变 量 ， 如 年 龄 age，Visitor 就 需要 修 


改 ， 如 果 Visitor 是 一 个 还 好 办 ， 多 个 呢 ? 业务 逻辑 再 复杂 点 呢 ? 


-> 


e 违背 了 依赖 倒置 转 原则 





访问 者 依赖 的 是 具体 元 素 ， 而 不 是 抽象 元 素 ， 这 破坏 了 依赖 倒置 原 
则 ， 特 别 是 在 面向 对 象 的 编程 中 ， 抛 弃 了 对 接口 的 依赖 ， 而 直接 依赖 实 
现 类 ， 扩 展 比较 难 。 





25.3.3 访问 者 模式 的 使 用 场景 


e 一 个 对 象 结构 包含 很 多 类 对 象 ， 它 们 有 不 同 的 接口 ， 而 你 想 对 这 
些 对 象 实施 一 些 依 赖 于 其 具体 类 的 操作 ， 也 就 说 是 用 达 代 器 模式 已 经 不 
能 胜任 的 情景 。 





e 需要 对 一 个 对 象 结构 中 的 对 象 进行 很 多 不 同 并 且 不 相关 的 操作 ， 


而 你 想 避 免 让 这 些 操作 “污染 "这些 对 象 的 类 。 


忆 结 一 下 ， 在 这 种 地 方 你 一 定 要 考虑 使 用 访问 者 模式 : 业务 规则 要 
求 过 历 多 个 不 同 的 对 象 。 这 本 映 也 是 访问 者 模式 出 发 点 ， 友 代 器 模式 只 
能 访问 同类 或 同 接口 的 数据 (当然 了 ， 如 果 你 使 用 instanceof， 那 么 能 访 
问 所 有 的 数据 ， 这 没有 争论 ) ， 而 访问 者 模式 是 对 迭代 器 模式 的 扩充 ， 
可 以 遍历 不 同 的 对 象 ， 然 后 执行 不 同 的 操作 ， 也 惑 是 针对 访问 的 对 象 不 
同 ， 执 行 不 同 的 操作 。 访 问 者 模式 还 有 一 个 用 途 ， 就 是 充当 拦截 器 
CInterceptor) 角色 ， 这 个 我 们 将 在 混 编 模式 中 讲解 。 





25.4 访问 者 模式 的 扩展 











访问 者 模式 是 经 疝 用 到 的 模式 ， 虽 然 你 不 注意 ， 有 可 能 你 起 的 名 字 
也 不 是 什么 Visitor， 但 是 它 确 实 是 非常 容易 使 用 到 的 ， 在 这 里 我 提出 两 
个 扩展 的 功能 供 大 家 参考 。 





25.4.1 统计 功能 


在 例子 中 我 们 也 提 到 访问 者 的 统计 功能 ， 汇 总 和 报表 是 金融 类 企业 
非常 常用 的 功能 ， 基 本 上 都 是 一 堆 的 计算 公式 ， 然 后 出 一 个 报表 ， 很 多 
项 目 采 用 了 数据 库 的 存储 过 程 来 实现 ， 我 不 是 很 推荐 这 种 方式 ， 除 非 海 
量 数据 处 理 ， 一 个 晚上 要 批 处 理 上 亿 、 几 十 亿 条 的 数据 ， 除 了 存储 过 程 
来 处 理 还 没有 其 他 办 法 ， 你 要 是 用 应 用 服务 器 来 处 理 ， 连 接 数 据 库 的 网 
络 就 是 处 于 100% 占 用 状态 ， 一 个 晚上 也 未 必 能 处 理 完 这 批 数据 ! 除了 
这 种 海量 数据 外 ， 我 建议 数据 统计 和 报表 的 批 处 理 通过 访问 者 模式 来 处 
理会 比较 简单 。 好 ， 那 我 们 来 统计 一 下 公司 人 员 的 工资 总 额 ， 先 看 类 
图 ， 如 图 25-6 所 示 。 











tvisit(CommonEmployee commonEmployee) 
tvoid visit(Manager manager) 
+nt getTotalSalary() 









-mt salary 
-String name 
-mt sex 


+getter/setter salary() 
+getter/setter name() 
tgetter/setter sex() 

+vold report() 

tHvoid accept(IVisitor visitor) 


图 25-6 统计 功能 的 访问 者 模式 


没什么 变化 ?仔细 看 IVisitor 接 口 ， 增 加 了 一 个 getTotalSalary 方 法 ， 
在 Visitor 实 现 类 中 实现 该 方法 。 我 们 先 看 接口 ， 如 代码 清单 25-17 所 示 。 





代码 清单 25-17 抽象 访问 者 


public interface IVisitor { 
// 首 先 定义 我 可 以 访问 普通 员工 
public void visit(CommonEmployee commonEmployee); 
// 其 次 定义 ， 我 还 可 以 访问 部 门 经 理 
public void visit(Manager manager ) ; 
// 统 计 所 有 员工 工资 总 和 
public int getTotalSalary() 























这 束 多 了 一 个 getTotalSalary 方 法 。 我 们 再 来 看 实现 类 ， 如 代码 清单 


25-18 所 示 。 


代码 清单 25-18 具体 访问 者 


public class Visitor implements IVisitor { 

// 部 门 经 理 的 工资 系数 是 5 

private final static int MANAGER COEFFICIENT = 5; 

// 员 工 的 工资 系数 是 2 

private final static int COMMONEMPLOYEE COEFFICIENT = 2; 

// 普 通 员工 的 工资 总 和 

private int commonTotalSalary = 0; 

// 部 门 经 理 的 工资 总 和 

private int managerTotalSalary =0; 

// 计 算 部 门 经 理 的 工资 总 和 

private void calManagerSalary(int salary)t 
this.managerTotalSalary = this.managerTotalSalary + 
*MANAGER_COEFFICIENT ; 






























































} 

// 计 算 普 通 员 工 的 工资 总 和 

private void calCommonSlary(int salary)t{ 
this.commonTotalSalary = this.commonTotalSalary + 
salary*COMMONEMPLOYEE_ COEFFICIENT; 








} 
// 获 得 所 有 员工 的 工资 总 和 
public int getTotalSalary(){ 
return this.commonTotalSalary + this.managerTotalSal 
} 





员工 和 经 理 层 的 信息 就 不 再 展示 了 ， 请 参考 代码 清单 25-6。 程 序 还 
是 比较 简单 的 ， 分 别 计 算 普 通 员 工 和 经 理 级 员工 的 工资 总 和 ， 然 后 加 起 
来 。 注 意 ， 我 们 在 实现 时 已 经 考虑 员工 工资 和 经 理工 资 的 系数 不 同 。 


我 们 再 来 看 Client 类 的 模拟 ， 如 代码 清单 25-19 所 示 。 


代码 清单 25-19 场景 类 


public class Client { 
public static void main(String[|] args) { 
IVisitor visitor = new Visitor(); 
for(Employee emp:mockEmployee())t{ 
emp.accept(visitor); 


System.out.println(" 本 公司 的 月 工资 总 额 是 : "+visitor .get1 


其 中 mockEmployee 议 态 方 法 没有 任何 改动 ， 请 参考 代码 清单 25- 
10， 在 此 不 再 歼 述 。 运 行 结果 如 下 所 示 : 


姓名 : 性 薪水 : 工作 : 编写 Java 程 序 ， 绝 对 的 蓝领 、 
张 三 别 : 男 1800 昔 工 加 搬运 工 

姓名 : 性 薪水 : 工作 : 页 面 美 工 ， 审 美 素质 太 不 流行 
李 四 别 : 女 1900 本 

姓名 : 性 薪水 : 业绩 : 基本 上 是 负 值 ， 但 是 我 会 拍 马 
于 五 别 : 男 18750 屁 呀 





本 公司 的 月 工资 总 额 101150 


然后 你 想 修改 工资 的 系数 ， 没 有 问题 ! 想 换个 展示 格式 ， 也 没有 问 
题 ! 多 多 练习 吧 ， 这 都 是 非常 简单 的 。 


25. 外 多 小 人 态 问 兰 


在 实际 的 项 目 中 ， 一 个 对 象 ， 多 个 访问 者 的 情况 非常 多 。 其 实 我 们 
上 面 例子 就 应 该 是 两 个 访问 者 ， 为 什么 呢 ? 报表 分 两 种 : 第 一 种 是 展示 
表 ， 通 过 数据 库 但 询 ， 把 结果 展示 出 来 ， 这 个 惑 类 似 于 我 们 的 那个 列 
表 ; 第 二 种 是 汇总 表 ， 这 个 是 需要 通过 模型 或 者 公式 计算 出 来 的 ， 一 般 
都 是 批 处 理 结 果 ， 这 个 类 似 于 我 们 计算 工资 忆 额 ， 这 两 种 报表 格式 是 对 
同一 堆 数 据 的 两 种 处 理 方式 。 从 程序 上 看 ， 一 个 类 就 有 个 不 同 的 访问 者 
了 。 修 改 一 下 类 图 ， 如 图 25-7 所 示 。 





类 图 看 着 挺 复杂 ， 其 实 也 没什么 复杂 的 ， 只 是 多 了 两 个 接口 和 两 个 
实现 类 ， 分 别 负责 展示 表 和 汇总 表 的 业务 处 理 ，IVisitor 接 口 没 有 改变 ， 
请 参考 代码 清单 25-5 所 示 代 码 ， 这 里 不 再 袭 述 。 我 们 来 看 展示 报表 接 
口 ， 如 代码 清单 25-20 所 示 。 








代码 清单 25-20 展示 表 接 口 


public interface IShowVisitor extends IVisitor { 
// 展 示 报 表 
public void report(); 


展示 表 的 实现 也 比较 简单 ， 如 代码 清 蛙 25-21 所 示 。 


代码 清单 25-21 具体 展示 表 


public class ShowVisitor implements IShowVisitor { 
private String info = ""; 


// 打 印 出 报表 
public void report() { 
System.out ,println(this.info)， 


} 
// 访 问 普 通 员 工 ， 组 六 信息 
public void visit(CommonEmployee commonEmployee) { 
this.info = this.info + this.getBasicIinfo(commonEmploye 
+ "工作 : "+commonEmployee.getJob()+"\t\n"; 


} 
// 访 问 经 理 ， 然 后 组 装 信息 
public void visit(Manager manager ) { 
this.info = this.info + this.getBasicIinfo(manager) + " 
"+manager .getPerformance() + "\t\n"; 


} 
// 组 装 出 基本 信息 
private String getBasicIinfo(Employee employee)t{ 

String info = "姓名 : " + employee.getName() + "\t"; 

info = info + "性 别 : " + (employee.getSex() == Employee. 
i )") 证 WANE 
info = info + "薪水 : " + employee.getSalary() + "Nt" 
return info; 
























































<<interface>> 
IVisitor 


+visit(CommonEmployee commonEmployee) 
+vold visit(Manager manager) 


八 人 


=<interface>> i <<mterface>> 
IShowVisitor i ITotalVisitor | |: 


+void report() +void totalSalary() 


ShowVisitor | © | Totalvisitor 


Employvee 


+petter/setter salary() 


tpgetter/setter name() 
+getter/setter sex() 

+void report() 

+void accepi(IVisitor visitor) 





-Strng job 
+getter/setter job() 


图 25-7 多 访问 者 的 类 图 





汇总 表 实 现 数据 汇总 功能 ， 其 接口 如 代码 清单 25-22 所 示 。 





代码 清单 25-22 汇总 表 接 口 


public interface ITotalVisitor extends IVisitor { 
// 统 计 所 有 员工 工资 总 和 
public void totalSalary(); 





就 一 句 话 ， 非 党 简单 ， 我 们 再 来 看 具体 的 汇总 表 访 问 者 ， 如 代码 清 
单 25-23 所 示 。 


代码 清单 25-23 具体 汇总 表 


public class TotalVisitor implements ITotalVisitor { 

// 部 门 经 理 的 工资 系数 是 5 

private final static int MANAGER_COEFFICIENT = 5; 

// 员 工 的 工资 系数 是 2 

private final static int COMMONEMPLOYEE COEFFICIENT = 2; 

// 普 通 员 工 的 工资 总 和 

private int commonTotalSalary = 

// 部 门 经 理 的 工资 总 和 

private int managerTotalSalary =0; 

public void totalSalary() { 
System.out.printLn(" 本 公司 的 月 工资 总 额 是 " + (this.commonTot1 
this.managerTotalSsSalary ) ) ， 












































} 

// 访 问 普 通 员 工 ， 计 算 工 资 总 额 

public void visit (CommonEmployee commonEmployee) { 
this.commonTotalSalary = this.commonTotalSalary + commo 




















} 
// 访 问 部 门 经 理 ， 计 算 工 资 总 额 
public void visit (Manager manager) { 
this.managerTotalSalary = this.managerTotalSalary + man 
} 





最 后 看 我 们 的 场景 类 如 何 计 算出 工资 总 额 ， 如 代码 清单 25-24 所 


代码 清单 25-24 场景 类 


public class Client { 
public static void main(String[] args) { 


// 展 示 报 表 访 问 者 

IShowVisitor showVisitor = new ShowVisitor(); 

// 汇 总 报表 的 访问 者 

ITotalVisitor totalVisitor = new TotalVisitor(); 

for(Employee emp:mockEmployee())t{ 
emp.accept(showVisitor); // 接 受 展示 报表 访问 者 
emp.accept(totalVisitor );// 接 受 汇 总 表 访 问 者 








} 
// 展 示 报 表 
showVisitor.report(); 
// 汇 总 报表 
totalVisitor.totalSsSalary( ) ， 
} 
} 
运行 结果 如 下 所 示 : 
姓名 : 薪水 : 工作 : 编写 Java 程 序 ， 绝 对 的 蓝领 
张 三 : 男 1800 苗 工 加 搬运 工 
姓名 : 薪水 : 工作 : 页 面 美 工 ， 审 美 素质 太 不 流行 
李 四  ” 别 : 女 1900 村， 
姓名 : 薪水 : 业绩 : 基本 上 是 负 值 ， 但 是 我 会 拍 马 
i 18750 屁 啊 


本 公司 的 月 工资 总 额 是 101150 


大 家 可 以 再 深入 地 想象 ， 一 堆 数 据 从 几 个 角度 来 分 析 ， 那 是 什么 ? 
即 数据 挖掘 (Data Mining) ， 数 据 的 上 切 、 下 钻 等 处 理 ， 大 家 有 兴趣 看 
可 以 翻 看 数据 挖掘 或 者 商业 智能 (BI) 的 书 。 


25 43 双人 必 





派 


说 到 访问 者 模式 就 不 得 不 提 一 下 双 分 派 〈double dispatch) 问题 ， 
什么 是 双 分 派 呢 ? 我 们 先 来 解释 一 下 什么 是 单 分 派 〈single dispatch) 和 
多 分 派 《multiple dispatch) ， 单 分 派 语言 处 理 一 个 操作 是 根据 请 求 者 的 
名 称 和 接收 到 的 参数 决定 的 ， 在 Java 中 有 静态 绑 定 和 动态 绑 定 之 说 ， 它 
的 实现 是 依据 重 载 (overload) 和 和 履 写 〈override) 实现 的 ， 我 们 来 说 一 
个 简单 的 例子 。 








例如 ， 演 员 演 电影 角色 ， 一 个 演员 可 以 扮演 多 个 角色 ， 我 们 先 定 义 
一 个 影视 中 的 两 个 角色 : 功夫 主角 和 白痢 配角 ， 如 代码 清单 25-25 所 


钞 。 





代码 清单 25-25 角色 接口 及 实现 类 


public interface Role { 


// 演 员 要 扮演 的 角色 





R 





public class KungFuRole implements Role { 


// 武 功 天 下 第 一 的 角色 


public class IdiotRole implements Role { 
// 一 个 弱智 角色 
} 








角色 有 了 ， 我 们 再 定义 一 个 演员 抽象 类 ， 如 代码 清单 25-26 所 示 。 


代码 清单 25-26 抽象 演员 


public abstract class AbsActor { 
// 演 员 都 能 够 演 一 个 角色 
public void act(Role role)t{ 
System.out.println(" 演 员 可 以 扮演 任何 角色 ")， 
} 














// 可 以 演 功 夫 戏 

public void act(KungFuRole role)t{ 
System.out.println(" 演 员 都 可 以 演 功夫 和 角色")， 

} 








很 简单 ， 这 里 使 用 了 Java 的 重 载 ， 我 们 再 来 看 青年 演员 和 老年 演 
员 ， 采 用 和 履 写 的 方式 来 细 化 抽象 类 的 功能 ， 如 代码 清单 25-27 所 示 。 


代码 清单 25-27 青年 演员 和 老年 演员 


public class YoungActor extends AbsActor { 
// 年 轻 演员 最 喜欢 演 功夫 戏 
public void act(KungFuRole role)t{ 
System.out.println(" 最 喜欢 演 功夫 角色 "); 
} 


public class OldActor extends AbsActor { 
// 不 演 功夫 角 
public void act(KungFuRole role)t{ 
System.out.println(" 年 龄 大 了 ， 不 能 演 功 夫 角色 " ) ; 
} 











Ey 











履 写 和 重 载 都 已 经 实现 ， 我 们 编写 一 个 场景 ， 如 代码 清单 25-28 所 


代码 清单 25-28 场景 类 


public class Client { 

public static void main(String[|] args) { 
// 定 义 一 个 演员 
AbsActor actor = new OldActor(); 
// 定 义 一 个 角色 
Role role = new KungFuRole(); 
// 开 始 演戏 
actor.act(role); 
actor.act(new KungFuRole( )); 








猜 猜 看 运行 结果 是 什么 ? 很 简单 ， 运 行 结果 如 下 所 示 。 





演员 可 以 扮演 任何 角色 

年 龄 大 了 ， 不 能 演 功 夫 角 色 

重 载 在 编译 器 期 就 决定 了 要 调用 哪个 方法 ， 它 是 根据 role 的 表面 类 
型 而 决定 调用 act(Role role) 方 法 ， 这 是 静态 绑 定 ; 而 Actor 的 执行 方法 act 
则 是 由 其 实际 类 型 决定 的 ， 这 是 动态 绑 定 。 








一 个 演员 可 以 扮演 很 多 角色 ， 我 们 的 系统 要 适应 这 种 变化 ， 也 就 是 
根据 演员 、 和 角色 两 个 对 象 类 型 ， 完 成 不 同 的 操作 任务 ， 该 如 何 实现 呢 ? 
很 简单 ， 我 们 让 访问 者 模式 上 场 就 可 以 解决 该 问题 ， 只 要 把 角色 类 稍稍 
修改 即 可 ， 如 代码 清单 25-29 所 示 。 





代码 清单 25-29 引入 访问 者 模式 


public interface Role { 
// 演 员 要 扮演 的 角色 


public void accept(AbsActor actor); 





public class KungFuRole implements Role { 
// 武 功 天 下 第 一 的 角色 
public void accept(AbsActor actor){ 
actor.act(this); 
} 


public class IdiotRole implements Role { 
// 一 个 弱智 角色 ， 由 谁 来 扮演 
public void accept(AbsActor actor){ 
actor.act(this); 
} 


























场景 类 稍 有 改动 ， 如 代码 清单 25-30 所 示 。 


代码 清单 25-30 场景 类 


public class Client { 
public static void main(String[|] args) { 
// 定 义 一 个 演员 
AbsActor actor = new OldActor(); 
/人 X 定 义 一 个 角色 
Role role = new KungFuRole(); 
// 开 始 演戏 


role.accept(actor ); 








CE 


运行 结果 如 下 所 示 。 

年 龄 大 了 ， 不 能 演 功 夫 和 角色 

看 到 没 ? 不 管 演员 类 和 角色 类 怎么 变化 ， 我 们 都 能 够 找到 期 望 的 方 
法 运行 ， 这 就 是 双 反 派 。 双 分 派 意 味 痢 得 到 执行 的 操作 诀 定 于 请 求 的 种 


类 和 两 个 接收 者 的 类 型 ， 它 是 多 分 派 的 一 个 特例 。 从 这 里 也 可 以 看 到 
Java 是 一 个 文 持 双 分 派 的 单 分 派 语言 。 





25.5 最 佳 实践 


访问 者 模式 是 一 种 集中 规整 模式 ， 特 别 适 用 于 大 规模 重 构 的 项 目 ， 
在 这 一 个 阶段 需求 已 经 非常 清晰 ， 原 系统 的 功能 点 也 已 经 明确 ， 通 过 访 
问 者 模式 可 以 很 容易 把 一 些 功 能 进行 梳理 ， 达 到 最 终 目 的 一 一 功能 集中 
化 ， 如 一 个 统一 的 报表 运算 、UI 展 现 等 ， 我 们 还 可 以 与 其 他 模式 混纺 建 
立 一 套 目 己 的 过 滤 韦 或 者 拦截 髓 ， 请 大 家 参考 混纺 模式 的 相关 章节。 








第 26 半 ”状态 模式 


26.1 城市 的 纵 同 及 展 功臣 一 一 电 述 








现在 城市 发 展 很 快 ， 百 万 级 人 口 的 城市 很 多 ， 那 其 中 有 两 个 东西 的 
发 明 在 城市 的 发 展 中 起 到 非常 重要 的 作用 : 一 个 是 汽车 ， 男 一 个 是 电 
梯 。 汽 车 让 城市 可 以 横 回 扩展 ， 电 梯 让 城市 可 以 纵 问 延伸 ， 同 空中 伸 
展 。 汽 车 对 城市 的 发 展 我 们 束 不 说 了 ， 电 梯 ， 你 想 想 看 ， 如 果 没 有 电 
梯 ， 每 天 你 需要 有 息 15 层 楼 梯 ， 你 是 不 是 会 累 坏 了? 建筑 师 设计 了 一 个 没 
有 电梯 的 建筑 ， 投 资 者 肯定 不 愿意 投资 ， 那 也 是 建筑 师 的 耻辱 ， 今 天 我 
们 就 用 程序 表现 一 下 这 个 电 桂 是 怎么 运作 的 。 








我 们 每 天 都 在 乘 电梯 ， 那 我 们 来 看 看 电梯 有 哪些 动作 (了 映 财 到 Java 
中 就 是 有 多 少 方法 ) : 开门、 关门、 运行、 停止。 好 ， 我 们 就 用 程序 来 
实现 一 下 电梯 的 动作 ， 先 看 类 图 设计 ， 如 图 26-1 所 示 。 








<<interface>> 
ILift 
一 = 


+Vold open() 
+void close() 
+void run() 






| | 
| 


电梯 接口 ， 定 义 电 梯 的 4 个 动作 


+void top() 





图 26-1 电梯 的 类 图 


非常 简单 的 类 图 ， 定 义 一 个 接口 ， 然 后 是 一 个 实现 类 ， 然 后 业务 场 
景 类 Client 就 可 以 调用 ， 并 运行 起 来 ， 简 单 也 要 实现 出 来 。 看 看 该 程序 
的 接口 ， 如 代码 清单 26-1 所 示 。 


代码 清单 26-1 电梯 接口 


public interface ILift 
// 首 先 电 梯 门 开启 动作 
public void open( ); 
// 电 梯 门 可 以 开启 ， 那 当然 也 就 有 关闭 了 
public void close( ); 
// 电 梯 要 能 上 能 下 
public void run(); 
// 电 梯 还 要 能 停 下 来 
public void stop(); 











接口 有 了 ， 再 来 看 实现 类 ， 如 代码 清单 26-2 所 示 。 


代码 清单 26-2 电梯 实现 类 


public class Lift implements ILift { 
// 电 梯 门 关闭 
public void close() { 
System.out ,println(" 电 梯 门 关闭 ,.."); 


3 
// 电 梯 门 开启 


public void open() { 
System.,out.println(" 电 梯 门 开启 ,.."); 


l 
// 电 梯 开 始 运行 起 来 


public void run() { 


System.out.println(" 电 梯 上 下 运行 起 来 ...")， 


} 

// 电 梯 停 止 

public void stop() { 
System.out.println(" 电 梯 停 止 了 ..."); 











电梯 的 开 、 关 、 运 行 、 停 都 实现 了 ， 再 看 看 场景 类 是 
如 代码 清单 26-3 所 示 。 


代码 清单 26-3 场景 类 


public class Client { 
public static void main(String[|] args) { 

ILift lift = new Lift(); 
// 首 先是 电梯 门 开 启 ， 人 进去 
1ift.open(); 
// 然 后 电梯 门 关 闭 
1ift.close( ); 
// 再 然后 ， 电 宰 运 行 起 来 ， 向 上 或 者 向 下 
1ift.run(); 
// 最 后 到 达 自 的 地 ， 电 梯 停 下 来 
1ift.stop(); 


-一 


运行 的 结果 如 下 所 示 : 














EB 梯 门 开局 .… 





怎么 调用 的 ， 








BE 梯 门 关闭 ..… 











电梯 上 下 运行 起 来 ..… 























电梯 停止 了 .… 





太 简 单 的 程序 了 ! 每 个 程序 员 都 会 写 这 个 程序 ， 这 么 简单 的 程序 还 
拿 出 来 显摆 ， 是 不 是 太 小 看 我 们 的 智商 了 ? 非 也 ， 非 也 ， 我 们 继续 往 下 
分 析 ， 这 个 程序 有 什么 问题 ? 你 想 想 ， 电 梯 门 可 以 打开 ， 但 不 是 随时 都 
可 以 开 ， 是 有 前 提 条 件 的 。 你 不 可 能 电梯 在 运行 的 时 候 突 然 开 门 吧 ? ! 
电梯 也 不 会 出 现 停 止 了 但 是 不 开门 的 情况 吧 ? ! 那 要 是 有 也 是 事故 嘛 ， 
再 仔细 想 想 ， 电 梯 的 这 4 个 动作 的 执行 都 有 前 置 条 件 ， 有 具体 点 说 就 是 在 
特定 状态 下 才能 做 特定 事 ， 那 我 们 来 分 析 一 下 电 杨 有 了 哪些 特定 状态 。 

















e 局 门 状态 





按 了 电梯 上 下 按钮 ， 电 梯 门 开 ， 这 中 间 大 概 有 10 秒 的 时 间 ， 那 就 是 
属 门 状态 。 在 这 个 状态 下 电梯 只 能 做 的 动作 是 关门 动作 。 


e 团 门 状 态 


电梯 门 天 闭 了 ， 在 这 个 状态 下 ， 可 以 进行 的 动作 是 : 开门 《我 不 想 
坐 电 梯 了 )〉、 停 止 ( 态 记 按 路 层 号 了 ) 、 运 行 。 


e 运行 状态 


电梯 正在 跑 ， 上 下 窜 ， 在 这 个 状态 下 ， 电 标 只 能 做 的 是 停止 。 


e 停止 状态 


电梯 停止 不 动 ， 在 这 个 状态 下 ， 电 梯 有 两 个 可 选 动作 : 继续 运行 和 
开门 动作 。 


我 们 用 一 张 表 来 表示 电梯 状态 和 动作 之 间 的 关系 ， 如 图 26-2 所 示 。 












运行 (run ) 





开门 (open) 天 门 〈close) 停止 (stop) 





敞 门 状态 


闭 门 状态 





运行 状态 


停止 状态 

















图 26-2 电梯 状态 和 动作 对 应 表 (o 表 示 不 允许 ， 交 表示 人 允许 动作 ) 


看 到 这 张 表 后 ， 我 们 才 发 觉 ， 哦 ， 我 们 的 程序 做 得 很 不 严 谍 ， 好 ， 
我 们 来 修改 一 下 ， 如 图 26-3 所 示 。 


在 接口 中 定义 了 4 个 常量 ， 分 别 表 示 电 梯 的 4 个 状态 : 和 沿 门 状态 、 闭 
门 状态 、 运 行 状态 、 停 止 状态 ， 然 后 在 实现 类 中 电梯 的 每 一 次 动作 发 生 
都 要 对 状态 进行 判断 ， 判 断 是 否 可 以 执行 ， 也 就 是 动作 的 执行 是 否 符合 
业务 逻辑 ， 实 现 类 中 有 4 个 私有 方法 是 仅仅 实现 电梯 的 动作 ， 没 有 任何 
前 置 条 件 ， 因 此 这 4 个 方法 是 不 能 为 外 部 类 调用 的 ， 设 置 为 私有 方法 。 
我 们 先 看 接口 的 改变 ， 如 代码 清单 26-4 所 示 。 





4 个 常量 代表 电梯 的 4 个 状态 ~ 


tfinal static mt OPENING STATE=1 
+final static nt CLOSING STATE=2 
+fmal static mt RUNNING STATE=3 
+final static int STOPPING STATE=4 


+vold open() 
tvoid close() 
+void run() 
+vold stop() 


4 个 私有 方法 代表 的 是 没 下 -Vold close WithoutLogic() 
a -void openWithoutLogic() 
暴 并 于 ， 9 市 交 E - 

有 逻辑 判断 的 动作 执行 -void runWithoutLogic() 

-vold stopWithoutLogic() 





图 26-3 增加 了 状态 的 类 图 


代码 清单 26-4 电梯 接口 


public interface ILift { 
// 电 梯 的 4 个 状态 
public final static int OPENING_STATE = 1; // 沿 门 状态 
public final static int CLOSING_STATE = 2; // 闭 门 状态 
public final static int RUNNING_STATE = 3; // 运 行 状态 
public final static int STOPPING_STATE = 4; // 停 止 状态 
// 设 置 电梯 的 状态 


public void setState(int state); 


// 首 先 电梯 门 开 局 动作 

public void open( ) ; 

// 电 梯 门 可 以 开启 ， 那 当然 也 就 有 关闭 了 
public void close( ) ; 

// 电 梯 要 能 上 能 下 ， 运 行 起 来 

public void run(); 

// 电 梯 还 要 能 停 下 来 

public void stop(); 











这 里 增加 了 4 个 静态 常量 ， 并 增加 了 一 个 方法 setState， 设 置 电 梯 的 
状态 。 我 们 再 来 看 实现 类 是 如 何 实现 的 ， 如 代码 清单 26-5 所 示 。 





代码 清单 26-5 电梯 实现 类 


public class Lift implements ILift { 
private int state; 
public void setState(int state) { 
this.state = state,; 


} 
// 电 梯 门 关闭 
public void close() { 
// 电 梯 在 什么 状态 下 才能 关闭 
switch(this.state)t 
case OPENING_STATE: // 可 以 关门 ， 同 时 修改 电梯 状 夸 
this.closeWithoutLogic( ); 
this.setState(CLOSING STATE); 
break; 
case CLOSING_STATE: // 电 梯 是 关门 状态 ， 则 什么 都 丰 
//do nothing; 
break; 
case RUNNING_STATE: // 正 在 运行 ， 门 本 来 就 是 关闭 的 ， 
//do nothing; 
break; 
case STOPPING_STATE:; // 停 止 状态 ， 门 也 是 关闭 的 ， 
//do nothing; 
break; 








} 
// 电 梯 门 开启 
public void open() { 
// 电 梯 在 什么 状态 才能 开启 
switch(this.state)t{ 
case OPENING_STATE: // 闭 门 状态 ， 什 么 都 不 做 


//do nothing; 
break; 

case CLOSING_STATE: // 闭 门 状态 ， 则 可 以 开启 
this.openwithoutLogic( ); 
this.setState(OPENING STATE); 
break; 

case RUNNING_STATE: // 运 行 状态 ， 则 不 能 开门 ， 什 么 i 
//do nothing; 
break; 

case STOPPING_STATE: // 停 止 状态 ， 当 然 要 开门 了 
thlis,openwWithoutLogic( ) ， 
this.setState(OPENING STATE); 
break; 





} 
了 
// 电 梯 开 始 运行 起 来 


public void run() { 
switch(this.state)t 

case OPENING_STATE: // 敞 门 状 态 ， 什 么 都 不 做 
//do nothing; 
break; 

case CLOSING_STATE: // 闭 门 状态 ， 则 可 以 运行 
this.runwithoutLogic( ); 
this.setState(RUNNING_ STATE); 
break; 

case RUNNING_STATE: // 运 行 状态 ， 则 什么 都 不 做 
//do nothing; 
break; 

case STOPPING_STATE: // 停 止 状 态 ， 可 以 运行 
this.runwithoutLogic( ); 
this.setState(RUNNING_STATE); 


} 
// 电 梯 停 止 
public void stop() { 
switch(this.state)t 
case OPENING_STATE: // 敞 门 状态 ， 要 先 停 下 来 的 ， 什 么 都 不 
//do nothing; 
break; 
case CLOSING_STATE: // 闭 门 状态 ， 则 当然 可 以 停止 了 
this.stopwithoutLogic( ); 
this.setSstate(CLOSING_ STATE); 
break; 
case RUNNING_STATE: // 运 行 状态 ， 有 运行 当然 那 也 就 有 停止 
this.stopwithoutLogic( ); 
this,setState(CLOSING_STATE) ， 
break 
case STOPPING_STATE: // 停 止 状 态 ， 什 么 都 不 做 











//do nothing; 
break; 


} 
3 
// 纯 粹 的 电梯 关门 ， 不 考虑 实际 的 逻辑 


private void closewithoutLogic(){ 
System.out ,println(" 电 梯 门 关闭 ,.."); 


} 

// 纯 粹 的 电梯 开门 ， 不 考虑 任何 条 件 

private void openwithoutLogic( ){ 
System.out.println(" 电 梯 门 开启 ..."); 


} 

// 纯 粹 的 运行 ， 不 考虑 其 他 条 件 

private void runwithoutLogic(){ 

System.out .printlin(" 电 梯 上 下 运行 起 来 .， 


} 

// 单 纯 的 停止 ， 不 考虑 其 他 条 件 

private void stopwithoutLogic( ){ 
System.out.println(" 电 梯 停 止 了 ..."); 

} 




















J 


程序 有 点 长 ， 但 是 还 是 很 简单 的 ， 就 是 在 每 一 个 接口 定义 的 方法 中 


使 用 switch...case 来 判断 它 是 


个 符合 业务 逻辑 ， 然 后 运行 指定 的 动作 。 我 


舌 - 口 
们 重新 编写 一 个 场景 类 来 描述 一 下 该 环境 ， 如 代码 清单 26-6 所 示 。 


代码 清单 26-6 场景 类 


public class Client { 
public static void main(String[] args) 1{ 

ILift lift = new Lift(); 
// 电 梯 的 初始 条 件 应 该 是 停止 状态 
1ift.setState(ILift.STOPPING_ STATE); 
// 首 先是 电梯 门 开 启 ， 人 进去 
1ift.open(); 
// 然 后 电梯 门 关闭 
1ift.close( ); 
// 再 然后 ， 电 梯 运 行 起 来 ， 向 上 或 者 向 下 
1ift.run(); 
// 最 后 到 达 自 的 地 ， 电 梯 停 下 来 
1ift.stop(); 








在 业务 调用 的 方法 中 增加 了 电 栎 状态 判断 ， 电 梯 要 不 古 随 时 都 可 以 
开 的 ， 必 须 满足 一 定 条 件 才 能 开门 ， 人 才能 走 进 去 ， 我 们 设置 电梯 的 起 
台 是 俘 止 状态 ， 运 行 结果 如 下 所 示 : 








电梯 门 开局 .… 











梯 门 关闭 … 











电梯 上 下 运行 起 来 … 























外 梯 停 止 了 .… 





我 们 来 想 一 下 ， 这 段 程序 有 什么 问题 。 


e 电梯 实现 类 Lift 有 点 长 





长 的 原因 是 我 们 在 程序 中 使 用 了 大 量 的 switch...case 这 样 的 判断 
(if...else 也 是 一 样 )， 程 序 中 只 要 有 这 样 的 判断 就 避免 不 了 加 长 程序 ， 
而 且 在 业务 复杂 的 情况 下 ， 程 序 会 更 长 ， 这 就 不 是 一 个 很 好 的 习惯 了 ， 
较 长 的 方法 和 类 无 法 带 来 良好 的 维护 性 ， 毕 竞 ， 程 序 首先 是 给 人 阅读 
的 ， 然 后 才 是 机 器 执行 。 











e 扩 展 性 非常 兰 劲 


大 家 来 想 想 ， 电 梯 还 有 两 个 状态 没有 加 ， 是 什么 ? 通电 状态 和 断 电 
状态 ， 你 要 是 在 程序 增加 这 两 个 方法 ， 你 看 看 Open()、Close()、Run()、 
Stop(O 这 4 个 方法 都 要 增加 判断 条 件 ， 也 就 是 说 switch 判 断 体 中 还 要 增加 





case 项 ， 这 与 开 闭 原则 相 违 背 。 
e 非常 规 状 态 无 法 实现 


我 们 来 思考 我 们 的 业务 ， 电 梯 在 门 效 开 状 态 下 束 不 能 上 下 运行 了 
吗 ? 电梯 有 没有 发 生 过 只 有 运行 没有 堡 止 状 态 呢 《从 40 层 直接 附 到 1 层 
呆 ) ?电梯 故障 噬 ， 还 有 电梯 在 检修 的 时 候 ， 可 以 在 stop 状 态 下 不 开 
门 ， 这 也 是 正常 的 业务 需求 呀 ， 你 想 想 看 ， 如 果 加 上 这 些 判 断 条 件 ， 上 
面 的 程序 有 多 少 需要 修改 ? 虽然 这 些 痢 是 电梯 的 业务 逻辑 ， 但 是 一 个 类 
有 且 仅 有 一 个 原因 引起 类 的 变化 ， 单 一 职责 原则 ， 看 看 我 们 的 类 ， 业 务 
任务 上 一 个 小 小 的 增加 或 改动 都 使 得 我 们 这 个 电梯 类 产生 了 修改 ， 这 在 
项 目 开 及 上 是 有 很 大 风险 的 。 














既然 我 们 已 经 发 现 程序 中 有 以 上 问题 ， 我 们 怎么 来 修改 呢 ? 刚刚 我 
们 是 从 电梯 的 方法 以 及 这 些 方法 执行 的 条 件 去 分 机， 现在 我 们 换个 角度 
来 看 问题 。 我 们 来 想 ， 电 梯 在 具有 这 些 状 态 的 时 候 能 够 做 什么 事情 ， 也 
就 是 说 在 电梯 处 于 茶 个 具体 状态 时 ， 我 们 来 思考 这 个 状态 是 由 什么 动作 
触发 而 产生 的 ， 以 及 在 这 个 状态 下 电 标 还 能 做 什么 事情 。 例 如 ， 电 梯 在 
停止 状态 时 ， 我 们 来 思考 两 个 问题 : 


e 信 止 状态 是 怎么 来 的 ， 那 当然 是 由 于 电梯 执行 了 stop 方 法 而 来 
的 。 


e 在 停止 状态 下 ， 电 梯 还 能 做 什么 动作 ?继续 运行 ? 开门 ? 当然 都 


可 以 了 。 


我 们 再 来 分 析 其 他 3 个 状态 ， 也 都 是 一 样 的 结果 ， 我 们 只 要 实现 电 
梯 在 一 个 状态 下 的 两 个 任务 模型 就 可 以 了 : 这 个 状态 是 如 何 产生 的 ， 以 
及 在 这 个 状态 下 还 能 做 什么 其 他 动作 (也 就 是 这 个 状态 怎么 过 渡 到 其 他 
状态 ) ， 既 然 我们 以 状态 为 参考 模型 ， 那 我 们 就 先 定义 电梯 的 状态 接 
口 ， 类 图 如 图 26-4 上 所 示 。 





每 个 状态 下 还 是 有 4 个 方法 ， 
各 个 状态 下 的 实现 方法 是 不 同 的 
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承担 的 是 环境 角色 ， 也 就 是 封装 类 














OpenningState ClosingState 
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图 26-4 以 状态 作为 导 同 的 类 图 


在 类 图 中 ， 定 义 了 一 个 LiftState 抽 象 类 ， 声 明了 一 个 受 保护 的 类 型 
Context 变 量 ， 这 个 是 串联 各 个 状态 的 封装 类 。 封 装 的 目的 很 明显 ， 就 是 
电梯 对 象 内 部 状态 的 变化 不 说 调用 类 知晓 ， 也 就 是 迪 米 特 法 则 了 (我 的 
类 内 部 情 市 你 知道 得 越 少 越 好 ) ， 并 且 还 定义 了 4 个 具体 的 实现 类 ， 承 











担 的 是 状态 的 产生 以 及 状态 间 的 转换 过 渡 ， 我 们 先 来 看 LiftState 代 码 ， 
如 代码 清单 26-7 所 示 。 


代码 清单 26-7 抽象 电梯 状态 


public abstract class LiftSstatet 
// 定 义 一 个 环境 角色 ， 也 就 是 封装 状态 的 变化 引起 的 功能 变化 
protected Context context; 
public void setContext(Context _Context){ 
this.context = _context 


} 

// 首 先 电 梯 门 开启 动作 

public abstract void open(); 
// 电 梯 门 有 开启 ， 那 当然 也 就 有 关闭 了 
public abstract void close(); 
// 电 梯 要 能 上 能 下 ， 运 行 起 来 
public abstract void run(); 
// 电 梯 还 要 能 停 下 来 

public abstract void stop(); 




















抽象 类 比较 简单 ， 我 们 先 看 
类 ， 如 代码 清单 26-8 所 示 。 





代码 清单 26-8 敞 门 状 态 


public class OpenningState extends LiftState { 

// 开 启 当 然 可 以 关闭 了 ， 我 就 想 测试 一 下 电梯 门 开 关 功 能 

@Override 

public void close() { 
// 状 态 修改 
super.context.setLiftState(Context.closeingState); 
// 动 作 委 托 为 CloseState 来 执行 
super.context.getLiftState().close(); 


} 

// 打 开 电 梯 门 

@Override 

public void open() { 
System.,out.println(" 电 梯 门 开启 ,.."); 

} 





/7/ 门 开 着 时 电梯 就 运行 跑 ， 这 电梯 ， 吓 死 你 ! 
@Override 
public void run() { 

//do nothing; 


} 

// 开 门 还 不 停止 ? 

public void stop() { 
//do nothing; 

} 


我 来 解释 一 下 这 个 类 的 几 个 方法 ，Openning 状 态 是 由 open() 方 法 产 
生 的 ， 因 此 ， 在 这 个 方法 中 有 一 个 具体 的 业务 逻辑 ， 我 们 是 用 print 来 代 
替 了 。 在 Openning 状 态 下 ， 电 梯 能 过 渡 到 其 他 什么 状态 呢 ? 按照 现在 的 
定义 的 是 只 能 过 渡 到 Closing 状 态 ， 因 此 我 们 在 Close0 中 定义 了 状态 变 
更 ， 同 时 把 Close 这 个 动作 也 委托 了 给 CloseState 类 下 的 Close 方 法 执行 ， 
这 个 可 能 不 好 理解 ， 我 们 再 看 看 Context 类 可 能 好 理解 一 点 ， 如 代码 清单 
26-9 所 示 。 





代码 清单 26-9 上 下 文 类 


public class Context { 
// 定 义 出 所 有 的 电梯 状态 
public final static OpenningState openningState = new Openni 
public final static ClosingState closeingState = new Closing 
public final static RunningState runningState = new RunningS 
public final static StoppingState StoppingState = new Stoppi 
// 定 义 一 个 当前 电梯 状态 
private LiftState liftState; 
public LiftState getLiftState() { 

return liftState; 











public void setLiftState(LiftState liftState) { 
this.1liftState = liftState,; 
// 把 当前 的 环境 通知 到 各 个 实现 类 中 
this.1iftState.setContext(this); 


public void open(){ 
this.1iftState.open( ); 


public void close()t{ 
this.1iftState.close( ); 


public void run(){ 
this.1iftState.run(); 


} 

public void stop(){ 
this.1iftState.stop(); 

} 


结合 以 上 3 个 类 ， 我 们 可 以 这 样 理解 : Context 是 一 个 环境 角色 ， 它 
的 作用 是 串联 各 个 状态 的 过 渡 ， 在 LiftSate 抽 象 类 中 我 们 定义 并 把 这 
环境 角色 聚合 进来 ， 并 传递 到 子 类 ， 也 就 是 4 个 具体 的 实现 类 中 自己 根 
据 环境 来 决定 如 何 进行 状态 的 过 渡 。 关 闭 状态 如 代码 清单 26-10 所 示 。 





代码 清单 26-10 关闭 状态 


public class ClosingState extends LiftState { 
// 电 梯 门 关闭 ， 这 是 关闭 状态 要 实现 的 动作 
@Override 
public void close() { 
System.out .printlin(" 电 梯 门 关闭 ,.."); 


} 

// 电 梯 门 天 了 再 打开 

@Override 

public void open() { 
super.context.setLiftState(Context.openningState); 
super.context.getLiftState().open(); 


} 

// 电 梯 门 关 了 就 运行 ， 这 是 再 正常 不 过 了 

@Override 

public void run() { 
super.context.setLiftState(Context.runningState); // 
super.context.getLiftState().run(); 


} 
// 电 梯 门 关 着 ， 我 就 不 按 楼 层 


Q@Override 























public void stop() { 
super.context.setLiftState(Context.stoppingState); 
super.context.getLiftState().stop(); 


Cy 


运行 状态 如 代码 清单 26-11 所 示 。 


代码 清单 26-11 运行 状态 


public class RunningState extends LiftState { 
// 电 梯 门 关闭 ?这 是 肯定 记 
@Override 
public void close() { 
//do nothing 


} 
// 运 行 的 时 候 开 电梯 门 ? 你 疯 了 ! 电梯 不 会 给 你 开 的 
@Override 
public void open() { 
//do nothing 




















} 

// 这 是 在 运行 状态 下 要 实现 的 方法 

@Override 

public void run() { 
System.out.println(" 电 梯 上 下 运行 ..."); 





























} 

// 这 绝对 是 合理 的 ， 只 运行 不 停止 还 有 谁 敢 坐 这 个 电梯 ? ! 估计 只 有 上 帝 了 

@Override 

public void stop() { 
super.context.setLiftState(Context.stoppingState);// 
super.context.getLiftState().stop(); 


























停止 状态 如 代码 清单 26-12 所 示 。 


代码 清单 26-12 停止 状态 


public class StoppingState extends LiftState { 
// 停 止 状态 关门 ”电梯 门 本 来 就 是 关 着 的 ! 
@Override 
public void close() { 


//do nothing; 





} 

// 停 止 状 态 ， 开 门 ， 那 是 要 的 ! 

@Override 

public void open() { 
super.context.setLiftState(Context.openningState); 
super.context.getLiftState().open(); 


} 

// 停 止 状态 再 运行 起 来 ， 正 常 得 很 

@Override 

public void run() { 
super.context.setLiftState(Context.runningState); 
super.context.getLiftState().run(); 


} 
// 停 止 状态 是 怎么 发 生 的 呢 ? 当然 是 停止 方法 执行 了 
@Override 
public void stop() { 

System.out .printlin(" 电 梯 停 止 了 ..."); 
} 











业务 逻辑 都 已 经 实现 了 ， 我 们 看 看 怎么 来 模拟 场景 类 ， 如 代码 清单 
26-13 上 所 示 。 


代码 清单 26-13 场景 类 


public class Client { 

public static void main(String[] args) { 
Context context = new Context( ) ; 
context .SetLiftState(new ClosingState( )); 
context .open() ; 
context .close() ; 
context .run( ) ， 
context.stop(); 


Client 场 景 类 太 简 单 了 ， 只 要 定义 一 个 电梯 的 初始 状态 ， 然 后 调用 
相关 的 方法 ， 就 完成 了 ， 完 全 不 用 考虑 状态 的 变更 ， 运 行 结果 完全 相 
同 ， 不 再 袭 述 。 


我 们 再 来 回顾 一 下 我 们 刚刚 批判 的 上 一 段 代码 。 首 先是 代码 太 长 ， 
这 个 问题 已 经 解决 了 ， 通 过 各 个 子 类 来 实现 ， 每 个 子 类 的 代码 都 很 短 ， 
而 且 也 取消 了 switch...case 条 件 的 判断 。 其 次 是 不 符合 开 闭 原则 ， 那 如 果 
在 我 们 这 个 例子 中 要 增加 两 个 状态 应 该 怎么 做 呢 ? 增加 两 个 子 类 ， 一 个 
是 通电 状态 ， 另 一 个 是 断 电 状态 ， 同 时 修改 其 他 实现 类 的 相应 方法 ， 因 
为 状态 要 过 渡 ， 那 当然 要 修改 原 有 的 类 ， 只 是 在 原 有 类 中 的 方法 上 增 
加 ， 而 不 去 做 修改 。 再 次 是 不 符合 迪 米 特 法 则 ， 我 们 现在 的 各 个 状态 是 
单独 的 类 ， 只 有 与 这 个 状态 有 关 的 因 又 修改 了 ， 这 个 类 才 修改 ， 符 合 迪 
米 特 法 则 ， 非 常 完美 ! 这 就 是 状态 模式 。 











26.2 状态 模式 的 定义 





上 面 的 例子 中 多 次 提 到 状态 ， 本 市 讲 的 束 是 状态 模式 ， 什 么 是 状态 
模式 呢 ? 其 定义 如 下 : 


Allow an objectto alter its behavior when its internal state changes.The 
object will appear to change its class.〈 当 一 个 对 象 内 在 状态 改变 时 允许 其 
改变 行为 ， 这 个 对 象 看 起 来 像 改变 了 其 类 。) 


状态 模式 的 核心 是 封装 ， 状 态 的 变更 引起 了 行为 的 变更 ， 从 外 部 看 
起 来 就 好 像 这 个 对 象 对 应 的 类 发 生 了 改变 一 样 。 状 态 模 式 的 通用 类 图 如 
图 26-5 所 示 。 
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图 26-5 状态 模式 通用 类 图 


我 们 先 来 看 看 状态 模式 中 的 3 个 角色 。 


@ State 


抽象 状态 角色 





接口 或 抽象 类 ， 负 责 对 象 状态 定义 ， 并 且 封 装 环境 角色 以 实现 状态 
切换 。 


@ ConcreteState 


具体 状态 角色 





每 一 个 具体 状态 必须 完成 两 个 职责 : 本 状态 的 行为 管理 以 及 趋向 状 
态 处 理 ， 通 俗 地 说 ， 就 是 本 状态 下 要 做 的 事情 ， 以 及 本 状态 如 何 过 小 到 


环境 角色 


@ Context 








定义 客户 端 需要 的 接口 ， 并 且 负 责 具 体 状 态 的 切换 。 








状态 模式 相对 来 说 比较 复杂 ， 它 提供 了 一 种 对 物质 运动 的 另 一 个 观 
察 视 角 ， 通 过 状态 变更 促使 行为 的 变化 ， 就 类 似 水 的 状态 变更 一 样 ， 
碗 水 的 初始 状态 通过 加 热 转变 为 气态 ， 状 态 的 改变 同时 也 引起 
体积 的 扩大 ， 然 后 就 产生 了 一 个 新 的 行为 : 鸣 笛 或 顶 起 壶 盖 ， 瓦 特 就 是 

么 发 明 蒸 汽机 的 。 我 们 再 来 看 看 状态 模式 的 通用 源 代码 ， 首 先 来 看 抽 
象 环 境 角 色 ， 如 代码 清单 26-14 所 示 。 








代码 清单 26-14 抽象 环境 角色 


public 0 eS State 2 
| es Cntexts 
// 设 置 环境 角色 
public void setContext(Context _context)t{ 
this.context = _context,; 




















} 

// 行 为 1 
public abstract void handlel1( ); 
// 行 为 2 

public abstract void handle2(); 





抽象 环境 中 声明 一 个 环境 角色 ， 提 供 各 个 状态 类 自行 访问 ， 并 且 提 
供 所 有 状态 的 抽象 行为 ， 由 各 个 实现 类 实现 。 具 体 环境 角色 如 代码 清单 


26-15 所 示 。 





代码 清单 26-15 环境 角色 


public class ConcreteState1 extends State { 
@Override 
public void handle1() { 
// 本 状态 下 必须 处 理 的 逻 于 











IT 

















@Override 

public void handle2() { 
// 设 置 当前 状态 为 stat2 
super.context.setCurrentState(Context .STATE2); 
// 过 渡 到 state2 状 态 ， 由 Context 实 现 
super.context.handle2( ); 














public class ConcreteState2 extends State { 
@Override 
public void handle1() { 
// 设 置 当 前 状态 为 statel1 
Super .context ,SetCurrentState(Context .STATE1); 
// 过 渡 到 state1 状 态 ， 由 Context 实 现 
super.context.handle1( ); 

















@Override 
public void handle2() { 

// 本 状态 下 必须 处 理 的 逻辑 
} 


























具体 环境 角色 有 两 个 职责 : 处 理 本 状态 必须 完成 的 任务 ， 决 定 是 否 


可 以 过 渡 到 其 他 状态 。 我 们 再 来 看 环境 角色 ， 如 代码 清单 26-16 所 示 。 


代码 清单 26-16 具体 环境 角色 


public class Context { 
// 定 义 状态 
public final static State STATE1 
public final static State STATE2 
// 当 前 状态 
private State CurrentState 
// 获 得 当前 状态 
public State getCurrentState() { 





new ConcreteStatel1(); 
new ConcreteState2(); 


return CurrentState ， 


} 

// 设 置 当 前 状态 

public void setCurrentState(State currentState) { 
this.CurrentState = currentState; 
// 切 换 状态 
this.CurrentState.setcontext(this),; 


} 

// 行 为 委托 

public void handle1()t{ 
this.CurrentState.handle1( ); 


} 
public void handle2()t{ 
this.CurrentState.handle2( ); 


} 
} 

环境 角色 有 两 个 不 成 文 的 约束 : 

e 把 状态 对 象 声 明 为 静态 常量 ， 有 几 个 状态 对 象 束 声 明 几 个 静态 各 
量 。 


e 环境 角色 具有 状态 抽象 角色 定义 的 所 有 行为 ， 具体 执行 使 用 委托 
pa 
我 们 再 来 看 场景 类 如 何 执 行 ， 如 代码 清单 26-17 所 示 。 


代码 清单 26-17 具体 环境 角色 


public class Client { 
public static void main(String[] args) { 








// 定 义 环境 角色 

Context context = new Context(); 

// 初 始 化 状态 

context.setCurrentState(new ConcreteState1( )); 
// 行 为 执行 


context.handle1( ); 
context.handle2( ); 


看 到 没 ? 我 们 已 经 隐藏 了 状态 的 变化 过 程 ， 它 的 切换 引起 了 行为 的 
变化 。 对 外 来 说 ， 我 们 只 看 到 行为 的 发 生 改 变 ， 而 不 用 知道 是 状态 变化 
引起 的 。 





26.3 状态 柑 式 的 应 用 


26.3.1 状态 模式 的 优点 


e 结构 清晰 


避免 了 过 多 的 switch...case 或 者 if...else 语 句 的 使 用 ， 避 人 免 了 程序 的 复 
杂 性 ,提高 系统 的 可 维护 性 。 


e 如 循 设计 原则 





很 好 地 体现 了 开 闭 原则 和 单一 职员 原则 ， 每 个 状态 都 是 一 个 子 类 ， 





你 要 增加 状态 就 要 增加 子 类 ， 你 要 修改 状态 ， 你 只 修改 一 个 子 关 就 可 以 
本 5 
e 封 冯 性 非常 好 








这 也 是 状态 模式 的 基本 要 求 ， 状 态 变 换 放置 到 类 的 内 部 来 实现 ， 外 
部 的 调用 不 用 知道 类 内 部 如 何 实现 状态 和 行为 的 变换 。 


26.3.2 状态 模式 的 缺点 


状态 模式 既然 有 优点 ， 那 当然 有 缺点 了 。 但 只 有 一 个 缺点 ， 子 类 会 





太 多 ， 也 就 是 类 脱 胀 。 如 果 一 个 事物 有 很 多 个 状态 也 不 稀奇 ， 如 果 完 全 
使 用 状态 模式 就 会 有 太 多 的 子 类 ， 不 好 管理 ， 这 个 需要 大 家 在 项 目 中 目 
己 衡量 。 其 实 有 很 多 方式 可 以 解决 这 个 状态 问题 ， 如 在 数据 库 中 建立 一 
个 状态 表 ， 然 后 根据 状态 执行 相应 的 操作 ， 这 个 也 不 复杂 ， 看 大 家 的 习 
惯 和 嗜好 了 。 





26.3.3 状态 模式 的 使 用 场景 





e 行为 随 状 态 改变 而 改变 的 场景 








这 也 是 状态 模式 的 根本 出 发 点 ， 例 如 权限 设计 ， 人 员 的 状态 不 同 即 
使 执行 相同 的 行为 结果 也 会 不 同 ， 在 这 种 情况 下 需要 考虑 使 用 状态 模 
3 


e 条 件 、 分 文 判断 语句 的 蔡 代 者 


在 程序 中 大 量 使 用 switch 语 名 或 者 让 判断 语句 会 导致 程序 结构 不 清 
晰 ， 人 逻辑 混 乱 ， 使 用 状态 模式 可 以 很 好 地 避免 这 一 问题 ， 它 通过 扩展 子 
类 实现 了 条 件 的 判断 处 理 。 


26.3.4 状态 模式 的 注意 事项 





状态 模式 适用 于 当 茶 个 对 象 在 它 的 状态 发 生 改 变 时 ， 它 的 行为 也 随 


独 发 生 比 较 大 的 变化 ， 也 就 是 说 在 行为 受 状 态 约束 的 情况 下 可 以 使 用 状 
态 模式 ， 而 且 使 用 时 对 象 的 状态 最 好 不 要 超过 5 个 。 


26.4 最 佳 实践 

















上 面 的 例子 可 能 比较 复杂 ， 请 各 位 看 官 耐 心 看 ， 看 完 肯 定 有 所 收 
获 。 我 翻 遍 了 所 有 能 找 得 到 的 资料 〈 关 于 这 个 电梯 的 例子 也 是 由 
《Design Pattern for Dummies》 这 本 书 激发 出 来 的 ) ， 基 本 上 没有 一 本 
把 这 个 状态 模式 讲 透彻 的 (当然 ， 还 是 有 几 本 讲 得 不 错 ) ， 我 不 敢 说 我 
就 讲 得 透彻 ， 大 家 都 只 讲 了 一 个 状态 到 另 一 个 状态 的 过 渡 。 状 态 间 的 过 
渡 是 固定 的 ， 举 个 简单 的 例子 ， 如 图 26-6 所 示 。 





图 26-6 简单 状态 切换 示意 图 


这 个 状态 图 是 很 多 书 上 都 有 的 ， 状 态 A 只 能 切换 到 状态 B， 状 态 B 再 
切换 到 状态 C。 举 例 最 多 的 就 是 TCP 监 听 的 例子 。TCP 有 3 个 状态 : 等 待 
状态 、 连 接 状 态 、 断 开 状 态 ， 然 后 这 3 个 状态 按照 顺序 循环 切换 。 按 照 
这 个 状态 变更 来 讲解 状态 模式 ， 我 认为 是 不 太 合适 的 ， 为 什么 呢 ? 你 在 
项 目 中 很 少 看 到 一 个 状态 只 能 过 渡 到 男 一 个 状态 情形 ， 项 目 中 过 到 的 大 





多 数 情 况 痢 是 一 个 状态 可 以 转换 为 几 种 状态 ， 如 图 26-7 所 示 。 





图 26-7 复杂 状态 切换 示意 图 


状态 B 既 可 以 切换 到 状态 C， 又 可 以 切换 到 状态 D， 而 状态 D 也 可 以 
切换 到 状态 A 或 状态 B， 这 在 项 目 分 析 过 程 中 有 一 个 状态 图 可 以 完整 地 
展示 这 种 蜗 蛛 网 结构 ， 例 如 ， 一 些 收费 网 站 的 用 户 就 有 很 多 状态 ， 如 普 
通用 户 、 普 通 会 员 、VIP 会 员 、 日 金 级 用 户 等 ， 这 个 状态 的 变更 你 不 允 
许 跳 跃 ? ! 这 不 可 能 ， 所 以 我 在 例子 中 就 举 了 一 个 比较 复杂 的 应 用 ， 基 
本 上 可 以 实现 状态 间 目 由 切换 ， 这 才 是 最 经 常用 到 的 状态 模式 。 

















再 提 一 个 问题 ， 状 态 间 的 上 自由 切换 ， 那 会 有 很 多 种 呀 ， 你 要 挨个 去 
牢记 一 所 吗 ? 比如 上 面 那个 电梯 的 例子 ， 我 要 一 个 正常 的 电梯 运行 多 
辑 ， 规 则 是 开门 -> 关门 -> 运行 -> 停止 ， 还 要 一 个 紧急 状态 (如 火灾 ) 下 
的 运行 逻辑 ， 关 门 -> 停 止 ， 紧 和 急 状 态 时 ， 电 梯 当 然 不 能 用 了 ; 再 要 一 个 
维修 状态 下 的 运行 逻辑 ， 这 个 状态 任何 情况 都 可 以 ， 开 痢 门 电梯 运行 ? 
可 以 ! 门 来 回 开 关 ? 可 以 ! 永久 俘 止 不 动 ? 可 以 ! 那 这 怎么 实现 呢 ? 需 
要 我 们 把 已 经 有 的 儿 种 状态 按照 一 定 的 顺序 再 重新 组 六 一 下 ， 那 这 个 是 

















什么 模式 ? 什么 模式 ? 大 声 点 ! 建造 者 模式 ! 对 ， 建 造 模式 + 状态 模式 
会 起 到 非常 好 的 封 狼 作用 。 


更 进一步 ， 应 该 有 部 分 读者 做 过 工作 流 开 发 ， 如 果 不 是 土 制 框架 ， 
那么 就 应 该 有 个 状态 机 管理 (即使 是 土 制 框 架 也 应 该 有 ) ， 如 一 个 
Activity(《 市 点 ) 有 初始 化 状态 (Initialized State) 、 挂 起 状态 
(Suspended State) 、 完 成 状态 〈Completed State) 等 ， 流 程 实例 也 有 
这 么 多 状态 ， 那 这 些 状态 怎么 管理 呢 ? 通过 状态 机 (State Machine) 来 
管理 ， 那 状态 机 是 个 什么 东西 呢 ? 就 是 我 们 上 面 提 到 的 Context 类 的 升级 
变态 BOSS ! 


第 27 章 ”解释 器 模式 


27.1 四 则 运算 你 会 吗 


在 银行 、 证 券 类 项 目 中 ， 经 常会 有 一 些 模型 运算 ， 通 过 对 现 有 数据 
的 统计 、 分 析 而 预测 不 可 知 或 未 来 可 能 发 生 的 商业 行为 。 模 型 运算 大 部 
分 是 针对 海量 数据 的 ， 例 如 建立 一 个 模型 公式 ， 分 析 一 个 城市 的 消费 倾 
问 ， 进 而 影响 银行 的 营销 和 业务 扩张 方向 。 一 般 的 模型 运算 都 有 一 个 或 
多 个 运算 公式 ， 通 常 是 加 、 减 、 乘 、 除 四 则 运算 ， 侦 尔 也 有 指数 、 开 方 
等 复杂 运算 。 具 体 到 一 个 金融 业务 中 ， 模 型 公式 是 非常 复杂 的 ， 昌 然 只 
有 加 、 减 、 乘 、 除 四 则 运算 ， 但 是 公式 有 可 能 有 十 多 个 参数 ， 而 且 上 百 
个 业务 品 各 有 不 同 的 取 参 路 径 ， 同 时 相关 表 的 数据 量 都 在 百 万 级 。 呵 
呵 ， 复 末了 吧 ， 不 复杂 那 就 不 叫 金 融 业务 ， 我 们 来 讲 讲 运算 的 核心 
模型 公式 及 其 如 何 实现 。 

















业务 需求 : 输入 一 个 模型 公式 《加 、 减 运算 ) ， 然 后 输入 模型 中 
的 参数 ， 运 算出 结果 。 


设计 要 求 : 





e 公式 可 以 运行 时 编辑 ， 并 且 符 合 正常 算术 书写 方式 ， 例 如 a+b-c。 





e 局 扩展 性 ， 未 来 增加 指数 、 开 方 、 极 限 、 求 导 等 运算 答 写 时 较 少 
改动 。 


e 效率 可 以 不 用 考虑 ， 上 晚间 批量 运算 。 





需求 不 复杂 ， 大 仪 仅 对 数字 采用 四 则 运算 ， 每 个 程 友 员 都 可 以 写 出 
来 。 但 是 增加 了 增加 模型 公式 就 复杂 了 。 先 解释 一 下 为 什么 裔 要 公式 ， 
而 不 采用 直接 计算 的 方法 ， 例 如 有 如 下 3 个 公式 : 


e 业务 种 类 1 的 公式 : a+b+c-d。 
e 业务 种 类 2 的 公式 : a+b+e-d。 
e 业务 种 类 3 的 公式 : a-f。 


其 中 ，a、b、c、d、e、f 参 数 的 值 都 可 以 取得 ， 如 果 使 用 直接 计算 
数值 的 方法 需要 为 每 个 品种 写 一 个 算法 ， 目 前 仅仅 是 3 个 业务 种 类 ， 那 








上 百 个 品种 呢 ? 鞭 菜 了 吧 ! 建立 公式 ， 然 后 通过 公式 运算 才 是 王道 


O 


我 们 以 实现 加 、 减 算法 (由 于 篇 幅 所 限 ， 乘 、 除 法 的 运算 读者 可 以 
自行 扩展 ) 的 公式 为 例 ， 讲 解 如 何 解析 一 个 固定 语法 逻辑 。 由 于 使 用 话 
法 解析 的 场景 比较 少 ， 而 且 一 些 商 业 公 司 (如 SAS、SPSS 等 统计 分 析 软 





件 ) 都 文 持 类 似 的 规则 运算 ， 杀 目 编 写 语法 解析 的 工作 已 经 非常 少 ， 以 
下 例 程 采 用 逐步 分 析 方 法 ， 带 领 大 家 了 解 这 一 实现 过 程 。 

















想 想 公 式 中 有 什么 ? 仅 有 两 类 元 么 ;运算 元 素 和 运算 符号 ， 运 算 元 
素 就 是 指 8、b、c 等 符号 ， 需 要 具体 赋值 的 对 象 ， 也 叫做 终结 符号 ， 为 
什么 叫 终 结 符 号 呢 ? 因为 这 些 元 素 除了 需要 赋值 外 ， 不 需要 做 任何 处 
理 ， 所 有 运算 元 系 都 对 应 一 个 具体 的 业务 参数 ， 这 是 语法 中 最 小 的 单元 
逻辑 ， 不 可 再 拆 分 ， 运算 符 号 束 是 加 减 符 写 ， 需 要 我 们 编写 算法 进行 处 
理 ， 每 个 运算 符 写 都 要 对 应 处 理 单元 ， 耕 则 公式 无 法 运行 ， 运 算 符 写 也 
叫做 非 终 结 符 号 。 两 类 元 素 的 共同 点 是 都 要 被 解析 ， 不 同 点 是 所 有 的 运 
算 元 系 具 有 相同 的 功能 ， 可 以 用 一 个 类 表示 ， 而 运算 符 写 则 是 需要 分 别 
进行 解释 ， 加 法 需要 加 法 解析 器 ， 减 法 需要 减法 解析 器 。 分 析 到 这 里 ， 
我 们 就 可 以 先 画 一 个 简单 的 类 图 ， 如 图 27-1 所 示 。 






































图 27-1 初步 分 析 加 减法 类 图 


这 是 一 个 很 简单 的 类 图 ，VarExpression 用 来 解析 运算 元 素 ， 各 个 公 
式 能 运算 元 素 的 数量 是 不 同 的 ， 但 每 个 运算 元 素 都 对 应 一 个 
VarExpression 对 象 。SybmolExpression 负 责 解 析 符 号 ， 由 两 个 子 类 








AddExpression (负责 加 法 运算 ) 和 SubExpression (负责 减法 运算 ) 来 实 
现 。 解 析 的 工作 完成 了 ， 我 们 还 需要 把 安排 运行 的 先后 顺序 (加 减法 不 
用 考虑 ， 但 是 乘除 法 呢 ? 注意 扩展 性 ) ， 并 且 还 要 返回 结果 ， 因 此 我 们 
需要 增加 一 个 封装 类 来 进行 封装 处 理 ， 由 于 我 们 只 做 运算 ， 暂 时 还 不 与 
业务 有 关联 ， 定 义 为 Calculator 类 。 分 析 到 这 里 ， 思 路 就 比较 清晰 了 ， 优 
化 后 加 减法 类 图 如 图 27-2 所 示 。 


Calculator 的 作用 是 封装 ， 根 据 迪 米 特 法 则 ，Client 只 与 直接 的 朋友 
Calculator 交 流 ， 与 其 他 类 没关系 。 整 个 类 图 的 结构 比较 清晰 ， 下 面 填充 
类 图 中 的 方法 ， 完 整 类 图 如 图 27-3 所 示 。 


类 图 已 经 完成 ， 下 面 来 看 代码 实现 。Expression 抽 象 类 如 代码 清单 
27-1 所 示 。 


代码 清单 27-1 抽象 表达 式 类 


public abstract class Expression { 
// 解 析 公 式 和 数值 ， 其 中 var 中 的 key 值 是 公式 中 的 参数 ，value 值 是 具体 的 数字 


public abstract int interpreter(HashMap<String,Integer> var) 








Es 





运算 元 素 解析 ~ 


图 27-2 优化 后 加 减法 类 图 
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图 27-3 完整 加 减法 类 图 














抽象 类 非常 简单 ， 仅 一 个 方法 interpreter 负 责 对 传递 进来 的 参数 和 值 
进行 解析 和 [匹配 ， 其 中 输入 参数 为 HashMap 类 型 ，key 值 为 模型 中 的 参 
数 ， 如 a、b、c 等 ，value 为 运算 时 取得 的 具体 数字 。 





变量 解析 器 如 代码 清 蛙 27-2 所 示 。 


代码 清单 27-2 变量 解析 器 


public class VarExpression extends Expression { 
private String key; 
public VarExpression(String _key)t{ 
this.key = _key; 


} 

// 从 map 中 取 之 

public int interpreter(HashMap<String, Integer> var) { 
return var.get(this.key); 








抽象 运算 符号 解析 器 如 代码 清单 27-3 所 示 。 








代码 清单 27-3 抽象 运算 符号 解析 器 


public abstract class SymbolExpression extends Expression { 
protected Expression left; 
protected Expression right; 
// 所 有 的 解析 公式 都 应 只 关心 自己 左右 两 个 表达 式 的 结果 
public SymbolExpression(Expression _left,Expression _right)t{ 
this.1left = _left,; 
this.right = _right; 











这 个 解析 过 程 还 是 比较 有 意思 的 ， 每 个 运算 符号 都 只 和 自己 左右 两 
个 数字 有 关系 ， 但 左右 两 个 数字 有 可 能 也 是 一 个 解析 的 结果 ， 无 论 何 种 
类 型 ， 都 是 Expression 的 实现 类 ， 于 是 在 对 运算 符 解 析 的 子 类 中 增加 了 
一 个 构造 函数 ， 传 递 左右 两 个 表达 式 。 具 体 的 加 、 减 法 解析 器 如 代码 清 
单 27-4、 代 码 清单 27-5 所 示 。 


代码 清单 27-4 加 法 解析 器 


public class AddExpression extends SymbolExpression { 
public AddExpression(Expression _left,Expression _right)t{ 
super(_left,_right); 


} 

// 把 左右 两 个 表达 式 运 算 的 结果 加 起 来 

public int interpreter(HashMap<String, Integer> Var) { 
return super.left.interpreter(var) + super.right.int 

} 








代码 清单 27-5 减法 解析 器 


public class SubExpression extends SymbolExpression { 
public SubExpression(Expression _left,Expression _right)t{ 
super(_left,_right); 


} 

// 左 右 两 个 表达 式 相 减 

public int interpreter(HashMap<String, Integer> var) { 
return super.left.interpreter(var) - super.right.int 

} 


解析 器 的 开发 工作 已 经 完成 了 ， 但 是 需求 还 没有 完全 实现 。 我 们 还 
需要 对 解析 器 进行 封装 ， 封 装 类 Calculator 如 代码 清单 27-6 所 示 。 


代码 清单 27-6 解析 右 封 装 类 


public class Calculator { 
// 定 义 表 达 式 
private Expression expression,; 
// 构 造 函 数 传 参 ， 并 解析 
public Calculator(String expStr)t{ 
// 定 义 一 个 栈 ， 安 排 运 算 的 先后 顺序 
Stack<Expression> stack = new Stack<Expression>(); 
// 表 达 式 拆 分 为 字符 数组 
char[] charArray = expStr.toCharArray(); 
// 运 算 
Expression left = null; 
Expression right = null; 
for(int i=0;i<charArray.length;i++)t{ 
switch(charArray[i]) { 
case '+': // 加 法 
// 加 法 结果 放 到 栈 中 
left = stack.pop(); 
right=new VarExpression(String.valueOof( 
stack.push(new AddExpression(left,right 
break; 
Case '-': 
left = stack.pop(); 
right=new VarExpression(String.valueOof( 
stack.push(new SubExpression(left,right 
break; 
default: // 公 式 中 的 变量 
stack.push(new VarExpression(String.val 
} 


























// 把 运算 结果 抛 出 来 


this.expression = stack.pop(); 


} 
// 开 始 运 算 
public int run(HashMap<String,Integer> var)t{ 
return this.expression.interpreter(var); 
} 


方法 比较 长 ， 我 们 来 分 析 一 下 ，Calculator 构 造 函 数 接收 一 个 表达 
式 ， 然 后 把 表达 式 转化 为 char 数 组 ， 并 判断 运算 符号 ， 如 果 是 “+” 则 进行 
加 法 运算 ， 把 左边 的 数 (left 变 量 ) 和 右边 的 数 (right 变 量 ) 加 起 来 就 
可 以 了 ， 那 左边 的 数 为 什么 是 在 栈 中 呢 ? 例如 这 个 公式 : atb-c， 根 据 
for 循 环 ， 首 先 被 压 入 栈 中 的 应 该 是 有 a 元 素 生 成 的 VarExpression 对 象 ， 
然后 判断 到 加 号 时 ， 把 a 元 素 的 对 象 VarExpression 从 栈 中 弹出 ， 与 右边 
的 数组 b 进 行 相 加 ，b 又 是 怎么 得 来 的 呢 ? 当前 的 数组 游标 下 移 一 个 单元 
格 即 可 ， 同 时 为 了 防止 该 元 素 再 次 被 遍历 ， 则 通过 ++i 的 方式 跳 过 
个 遍历 一 一 于 是 一 个 加 法 的 运行 结束 。 减 法 也 采用 相同 的 运行 原理 。 








为 了 满足 业务 要 求 ， 我 们 设置 了 一 个 Client 类 来 模拟 用 户 情况 ， 用 
户 要 求 可 以 扩展 ， 可 以 修改 公式 ， 那 就 通过 接收 键盘 事件 来 处 理 ， 
Client 类 如 代码 清单 27-7 所 示 。 


代码 清单 27-7 客户 模拟 类 


public class Client { 
// 运 行 四 则 运算 
public static void main(String[] args) throws IOException{ 
String expStr = getExpStr(); 
// 赋 值 
HashMap<String,Integer> Var = getValLue(expStr)， 


Calculator cal = new Calculator(expSstr); 
System,out.printlLn(" 运 算 结果 为 : "+expStr +"="+cal.run(var 


} 

// 获 得 表达 式 

public static String getExpStr() throws IOExceptiont{ 
System.out.print(" 请 输入 表达 式 : " )， 
return (new BufferedReader(new InputStreamReader(SySstem 


} 

// 获 得 值 映 射 

public static HashMap<String,Integer> getValue(String exprst 
HashMap<String,Integer> map = new HashMap<String,Intege 




















// 解 析 有 几 个 参数 要 传递 
for(char ch:exprSstr.tocCcharArray())t{ 
if(ch != '+' && ch != '-')t{ 


// 解 决 重复 参数 的 问题 

if(!'map.containsKkey(String.valueOof(ch)))t{ 
String in = (new BufferedReader(new Inpu 
map.put(String.valueof(ch),Integer.value 





} 


return map; 





其 中 ，getExpStr 是 从 键盘 事件 中 获得 的 表达 式 ，getValue 方 法 是 从 
键盘 事件 中 获得 表达 式 中 的 元 素 映 射 值 ， 运 行 过 程 如 下 。 








e 自 完 ， 要 求 输入 公式 。 





请 输入 表达 式 : a+b-c 
e 其 次 ， 要 求 输入 公式 中 的 参数 。 


请 输入 a 的 值 ，100 
请 输入 b 的 值 : 20 


请 输入 c 的 值 :40 


e 最 后 ， 运 行 出 结果 。 





运算 结果 为 : a+b-c=80 


看 ， 要 求 输入 一 个 公式 ， 然 后 输入 参数 ， 运 行 结果 出 来 了 ! 那 我 们 
古 不 是 可 以 修改 公式 ?当然 可 以 ， 我 们 只 要 输入 公式 ， 然 后 输入 相应 的 
值 就 可 以 了 ， 公 式 是 在 运行 时 定义 的 ， 而 不 是 在 运行 前 就 制定 好 的 ， 是 
不 是 类 似 于 初中 学 过 的 “代数 "这 门 读 ? 先 公 式 ， 然 后 赋值 ， 运 算出 结 
果 。 


需求 已 经 开发 完毕 ， 公 式 可 以 自由 定义 ， 只 要 符合 规则 (有 变量 有 
运算 符合 ) 就 可 以 运算 出 结果 ; 奋 需 要 扩展 也 非常 容易 ， 只 要 增加 
SymbolExpression 的 子 类 就 可 以 了 ， 这 就 是 解释 器 模式 。 





27.2 解释 级 模式 的 定义 


解释 器 模式 (Interpreter Pattern ) 是 一 种 按照 规定 语法 进行 解析 的 
方案 ， 在 现在 项 目 中 使 用 较 少 ， 其 定义 如 下 : Given a language, define a 





representation for its grammar along with an interpreter that uses the 





representation to interpret sentences in the language.〈 给 定 一 门 语 言 ， 定 义 
它 的 文法 的 一 种 表示 ， 并 定义 一 个 解释 器 ， 该 解释 器 使 用 该 表示 来 解释 
语言 中 的 句子 。) 





解释 器 模式 的 通用 类 图 如 图 27-4 所 示 。 














Client 


+Interpret() 


TerminalExpression NonterminalExpression 


图 27-4 解释 器 模式 通用 类 图 





抽象 解释 器 


® AbstractEXpression 


具体 的 解释 任务 由 各 个 实现 类 完成 ， 具 体 的 解释 需 分 别 由 


TerminalExpression 和 Non-terminalExpression 完 成 。 





终结 符 表 达 式 


e@ TerminalExpression 





实现 与 文法 中 的 元 素 相关 联 的 解释 操作 ， 通 常 一 个 解释 器 模式 中 内 
有 一 个 终结 符 表 达 式 ， 但 有 多 个 实例 ， 对 应 不 同 的 终结 和 从。 具体 到 我 们 
例子 就 是 VarExpression 类 ， 表 达 式 中 的 每 个 终结 符 都 在 栈 中 产生 了 一 个 
VarExpression 对 象 。 





非 终 结 符 表 达 式 


e NonterminalExpression 





文法 中 的 每 条 规则 对 应 于 一 个 非 终 结 表 达 式 ， 具 体 到 我 们 的 例子 就 
是 加 减法 规则 分 别 对 应 到 AddExpression 和 SubExpression 两 个 类 。 非 终结 
符 表 达 式 根据 逻辑 的 复杂 程度 而 增加 ， 原 则 上 每 个 文法 规则 都 对 应 一 个 
非 终结 符 表 达 式 。 











环境 角色 


@ Context 





有 共 体 到 我 们 的 例子 中 是 采用 HashMap 代 蔡 。 


解释 需 是 一 个 比较 少 用 的 模式 ， 以 下 为 其 通用 源码 ， 可 以 作为 参 
考 。 抽 象 表达 式 通 季 只 有 一 个 方法 ， 如 代码 清单 27-8 所 示 。 





代码 清单 27-8 抽象 表达 式 


public abstract class Expression { 
// 每 个 表达 式 必须 有 一 个 解析 任务 
public abstract Object interpreter(Context ctx); 





抽象 表达 式 是 生成 语法 集合 〈 也 叫做 语法 树 ) 的 关键 ， 每 个 语法 集 
合 完 成 指定 语法 解析 任务 ， 它 是 通过 递归 调用 的 方式 ， 最 终 由 最 小 的 语 
法 单元 进行 解析 完成 。 终 结 符 表 达 式 如 代码 清单 27-9 所 示 。 


代码 清单 27-9 终结 符 表达 式 


public class TerminalExpression extends Expression { 
// 通 常 终结 符 表 达 式 只 有 一 个 ， 但 是 有 多 个 对 象 
public Object interpreter(Context ctx) { 
return null; 
} 














通 第 ， 终 结 符 表 达 式 比较 人 简单， 主要 是 处 理 场景 元 系 和 数据 的 转 
换 。 


非 终结 符 表 达 陈 如 代码 清单 27-10 所 示 。 


代码 清单 27-10 非 终 结 符 表达 式 


public class NonterminalExpression extends Expression { 
// 每 个 非 终 结 符 表 达 式 都 会 对 其 他 表达 式 产生 依赖 
public NonterminalExpression(Expression... expression)t{ 


} 


public Object interpreter(Context ctx) { 
// 进 行文 法 处 理 
return null; 


























| 


每 个 非 终 结 符 表达 式 都 代表 了 一 个 文法 规则 ， 并 且 每 个 文法 规则 都 
只 关心 自己 周边 的 文法 规则 的 结果 (注意 是 结果 〉 ， 因 此 这 就 产生 了 每 
个 非 终 结 符 表 达 式 调用 自己 周边 的 非 终 结 符 表达 式 ， 然 后 最 终 、 最 小 的 
文法 规则 融 是 终结 符 表 达 式 ， 终 结 符 表达 式 的 概念 就 是 如 此 ， 不 能 够 再 
参与 比 自己 更 小 的 文法 运算 了 。 


客户 类 如 代码 清单 27-11 所 示 。 


代码 清单 27-11 客户 类 


public class Client { 
public static void main(String[|] args) { 
Context ctx = new Context( ) ; 
// 通 常 定 一 个 语法 容器 ， 容 纳 一 个 具体 的 表达 式 ， 通 常 为 ListArray、Lil 
Stack&Expression> stack = null; 
for(;;)t 
// 进 行 语法 判断 ， 并 产生 递归 调用 
} 
// 产 生 一 个 完整 的 语法 树 ， 由 各 个 具体 的 语法 分 析 进 行 解析 
Expression exp = stack.pop(); 


// 有 具体 元 素 进 入 场景 
exp.interpreter(ctx); 












































通 冲 Client 是 一 个 封装 类， 封 逆 的 结果 就 是 传递 进来 一 个 规范 语法 
文件 ， 解 析 器 分 析 后 产生 结果 并 返回 ， 避 免 了 调用 者 与 语法 解析 器 的 灰 
合 关 系 。 


27.3 解释 瞩 模 式 的 应 用 
27.3.1 解释 器 模式 的 优点 
解释 器 是 一 个 简单 语法 分 析 工具 ， 它 最 显著 的 优点 就 是 扩展 性 ， 修 


改 语法 规则 只 要 修改 相应 的 非 终 结 符 表达 式 束 可 以 了 ， 奋 扩展 语法 ， 则 
只 要 增加 非 终 结 符 类 就 可 以 了 。 





27.3.2 解释 器 模式 的 缺 反 


e 解释 占 模 式 会 引起 类 膨胀 


每 个 语法 都 要 产生 一 个 非 终结 符 表 达 式 ， 语 法 规则 比较 复杂 时 ， 囊 
可 能 产生 大 量 的 类 文件 ， 为 维护 带 来 了 非常 多 的 麻烦 。 





e 解释 器 模式 采用 递归 调用 方法 








每 个 非 终结 符 表 达 式 只 关心 与 自己 有 关 的 表达 式 ， 每 个 表达 式 需 要 
知道 最 终 的 结果 ， 必 须 一 层 一 层 地 和 剥 理 ， 无 论 是 面 癌 过程 的 语言 还 是 面 
加 对 象 的 语言 ， 递 归 都 是 在 必要 条 件 下 使 用 的 ， 它 导致 调试 非常 复杂 。 
想 想 看 ， 如 果 和 要 排查 一 个 语法 错误 ， 我 们 是 不 是 要 一 个 断 点 一 个 断 点 地 
调试 下 去 ， 直 到 最 小 的 语法 单元 。 





e 效率 问题 


解释 器 模式 由 于 使 用 了 大 量 的 循环 和 递归 ， 效 率 是 一 个 不 容 忽视 的 
问题 ， 特 别 是 一 用 于 解析 复 茶 、 元 长 的 语法 时 ， 效 率 是 难以 丸 受 的 。 





27.3.3 解释 器 模式 使 用 的 场景 


e 重复 发 生 的 问题 可 以 使 用 解释 器 模式 





例如 ， 多 个 应 用 服务 器 ， 每 天 产生 大 量 的 日 志 ， 需 要 对 日 志文 件 进 
行 分 析 处 理 ， 由 于 各 个 服务 器 的 日 志 格 式 不 同 ， 但 古 数据 要 素 是 相同 
的 ， 按 照 解释 露 的 说 法 就 是 终结 符 表 达 式 都 是 相同 的 ， 但 是 非 终结 符 表 
达 式 就 需要 制定 了 。 在 这 种 情况 下 ， 可 以 通过 程序 来 一 达 水 逸 地 解决 该 


问题 。 








e 一 个 简单 语法 需要 解释 的 场景 





为 什么 是 简单 ? 看 看 非 终 结 表达 式 ， 文 法 规则 越 多 ， 复 杂 度 越 高 ， 
而 且 类 间 还 要 进行 递归 调用 《看 看 我 们 例子 中 的 栈 ) 。 想 想 看 ， 多 个 类 
之 间 的 调用 你 需要 什么 样 的 耐心 和 信心 去 排查 问题 。 因 此 ， 解 释 器 模式 
一 般 用 来 解析 比较 标准 的 字符 集 ， 例 如 SQL 语 法 分 析 ， 不 过 该 部 分 逐渐 
被 专用 工具 所 取代 。 





在 某 些 特 用 的 商业 环境 下 也 会 采用 解释 右 模 式 ， 我 们 刚刚 的 例子 区 





古 一 个 商业 环境 ， 而 且 现 在 模型 运算 的 例子 非常 多 ， 目 前 很 多 两 业 机 构 
己 经 能 够 提供 出 大 量 的 数据 进行 分 析 。 


27.3.4 解释 器 模式 的 注意 事项 


尽量 不 要 在 重要 的 模块 中 使 用 解释 器 模 式 ， 人 否则 维护 会 是 一 个 很 大 
的 问题 。 在 项 目 中 可 以 使 用 shell、JRuby、Groovy 等 脚本 语言 来 代替 解 
释 絮 模式 ， 弥 补 Java 编 译 型 语言 的 不 足 。 我 们 在 一 个 银行 的 分 析 型 项 目 
中 就 采用 JRuby 进 行 运算 处 理 ， 避 免 使 用 解释 器 模式 的 四 则 运算 ， 效 率 
和 性 能 各 方面 表现 民 好 。 


27.4 最 佳 实践 


解释 堪 模 式 在 实际 的 系统 开发 中 使 用 得 非常 少 ， 因 为 它 会 引起 效 
率 、 性 能 以 及 维护 等 问题 ， 一 般 在 大 中 型 的 框架 型 项 目 能 够 找到 它 的 号 
， 如 一 些 数据 分 析 工 具 、 报 表 设 计 工具 、 科 学 计算 工具 等 ， 若 你 确实 
遇 到 “一 种 特定 类 型 的 问题 发 生 的 频率 足够 高 ”的 情况 ， 准 备 使 用 解释 器 
模式 时 ， 可 以 考虑 一 下 Expression4J、MESP (Math Expression String 
Parser) 、Jep 等 开源 的 解析 工具 包 〈 这 三 个 开源 产品 都 可 以 通过 百度 、 
Google 搜 索 到 ， 请 读者 自行 查询 ) ， 功 能 都 异常 强大 ， 而 且 非 常 容 易 使 
用 ， 效 率 也 还 不 错 ， 实 现 大 多 数 的 数学 运算 完全 没有 问题 ， 自 己 没有 必 
要 从 头 开始 编写 解释 器 。 有 人 已 经 建立 了 一 条 康 庄 大 道 ， 何 必 再 走 自 己 
的 泥 尝 小 路 呢 ? 








第 28 章 ”至 元 模式 


28.1 内 存 溢出 ， 司 空 见 惯 


下 午 ， 我 正在 开会 中 ， 老 大 推 门 进来 。 
“三 作 s 出 来 一 下 y” 
我 刚 出 会 议 室 门口 ， 老 大 就 发 话 了 。 


“ 即 当 《〈 姓 明 ， 顺 口 就 叫 即 当 ) 的 那个 报考 系统 又 crash 了 一 合 机 
器 ， 两 天 已 丝 宕 了 4 次 了 ， 你 这 边 还 有 紧急 的 事情 没有 ? .…… 没 有 ， 那 
赶快 过 去 顶 一 下 ， 就 运行 三 天 的 程序 ， 两 天 宕 了 4 次 ， 还 怎么 玩 ? ! ” 








我 马上 收拾 东西 ， 冲 到 马路 上 拦 了 出 租车 ， 同 时 打 电 话 给 郎 当 。 


“三 可， 厂商 人 员 已 经 定位 出 了 ，OutOfMemory 内 存 洲 出 ， 没 查 到 
有 内 存 泄漏 的 情况 ， 现 在 还 在 跟踪 ..….... 是 突然 暴涨 的 ， 都 是 在 繁忙 期 出 
现 问 题 的 .………. 








内 存 游 出 对 Java 应 用 来 说 实在 是 太平 常 了 ， 有 以 下 两 种 可 能 


。 内存 泄漏 


无 意识 的 代码 缺陷 ， 导 致 内 存 泄漏 ，JVM 不 能 获得 连续 的 内 存 空 
间 。 


e@ 对 象 太 多 


代码 写 得 很 烂 ， 产 生 的 对 象 太 多 ， 内 存 和 被 耗 尽 。 现 在 的 情况 是 没有 
内 存 泄 漏 ， 那 只 有 一 种 原因 一 一 代码 太 关 把 内 存 耗 尽 。 


到 现场 后 ， 郎 当 给 我 介绍 了 一 下 系统 情况 。 该 系统 是 一 个 报考 系 
统 ， 其 中 有 一 个 模块 负责 社会 人 员 报 名 ， 该 模块 对 全 国 的 考试 人 员 只 开 
放 3 天 ， 并 且 限 制 报考 人 员 数 量 。 第 一 天 9 点 开始 报考 ， 系 统 慢 得 像 蜗 
牛 ， 基 本 上 都 不 能 访问 ， 后 来 设置 了 HTTP Server 的 并 发 数量 ， 稍 有 绥 
解 ，40 分 钟 后 宕 了 一 台 机 器 ，10 分 钟 后 ， 又 挂 了 一 台 ， 下 午 3 点 又 挂 了 
一 台 ， 看 样子 晚上 要 让 郎 当 去 寺庙 烧 烧 香 了 。 











该 系统 一 共有 8 人 台 应 用 服务 器 ， 基 本 上 CPU 繁忙 程度 都 在 60% 以 
上 ，HTTP 的 最 大 并 发 是 2000， 平 均 分 配 到 每 台 应 用 服务 器 上 没有 太 大 
的 压力 ， 于 是 怀疑 是 代码 问题 ， 然 后 详细 了 解 了 一 下 业务 和 数据 流 逻 
辑 ， 基 本 的 业务 操作 过 程 清楚 了 ， 先 登录 (没有 账号 的 ， 则 要 先 注 
册 ) ， 登 录 后 ， 需 要 填写 以 下 信息 : 











e 考试 科目 ， 选 择 框 。 





e 考试 地 点 ， 选 择 框 ， 根 据 科 目 不 同 ， 列 表 不 同 。 


e 准 考 证 邮寄 地 址 ， 输 入 框 。 


还 有 其 他 一 堆 信 息 ， 我 们 以 这 三 者 作为 代表 来 讲解 。 信 息 填 写 完毕 
后 ， 点 击 人 确认， 报名 就 结束 了 。 人 简单 程序 的 业务 馆 辑 也 确实 是 这 样 ， 太 
什么 出 现 Crash 情 况 呢 ? 那 肯定 是 和 压力 有 关系 ! 


我 们 先 把 这 个 过 程 的 静态 类 图 画 出 来 ， 如 图 28-1 所 示 。 






SignInfo 


-String 1d 
| ; String location 
+SignInfo getSignInfo() -String subject 


-getLocation 





SignlInfoFactory 





+getter/setter() 


图 28-1 报考 系统 类 图 


很 简单 的 工 广 方法 模式 ， 表 现 层 通过 工厂 方法 模式 创建 对 象 ， 然 后 
传递 给 业务 层 和 持久 层 ， 最 终 保 存 到 数据 库 中 ， 为 什么 要 使 用 工 三 方法 








模式 而 不 用 直接 new 一 个 对 象 呢 ? 因为 是 在 框架 下 编程 ， 必 须 有 一 个 对 
象 工 厂 (ObjectFactory,Spring 也 有 对 象 工 三 〉，。 我 们 先 来 看 报考 信息 ， 
如 代码 清单 28-1 所 示 。 


代码 清单 28-1 报考 信息 


public class SignInfo { 
// 报 名 人 员 的 ID 
private String id; 
// 考 试 地 点 
private String location; 
// 考 试 科目 
private String subject; 
// 邮 寄 地 址 
private String postAddress,; 
public String getId() { 

return id; 


} 

public void setId(String id) { 
this.id = id; 

public String getLocation() { 
return location; 


public void setLocation(String location) { 
this.1location = location; 


public String getSubject() { 
return Subject ; 


public void setSubject(String subject) { 
this.subject = subject; 


} 
public String getPostAddress() { 
return postAddress; 


public void setPostAddress(String postAddress) { 
this.postAddress = postAddress; 
} 


它 是 一 个 很 简单 的 POJO 对 象 (Plain Ordinary Java Object， 简 单 Java 
对 象 ) 。 我 们 再 来 看 工厂 类 ， 如 代码 清单 28-2 所 示 。 


代码 清单 28-2 报考 信息 工厂 


public class SignInfoFactory { 
// 报 名 信息 的 对 象 工厂 
public static SignInfo getSignInfo(){ 
return new SignInfo(); 
} 








工厂 类 就 这 么 简单 ? 非 也 ， 这 是 我 们 的 教学 代码 ， 真 实 的 
ObjectFactory 要 复杂 得 多 ， 主 要 是 注入 了 部 分 Handler 的 管理 。 表 现 层 是 
如 何 创建 对 象 的 ， 如 代码 清单 28-3 所 示 。 





代码 清单 28-3 场景 类 


public class Client { 
public static void main(String[|] args) { 
// 从 工厂 中 获得 一 个 对 象 
SignInfo SignInfo = SignInfoFactory.getSignInfo( ); 
// 进 行 其 他 业务 处 理 


























就 这 么 简单 ， 但 是 简单 为 什么 会 出 现 问 题 呢 ? 而 且 这 样 写 也 没有 问 
题 呀 ， 很 标准 的 工 广 方法 模式 ， 应 该 不 会 有 大 问题 ， 然 后 又 看 了 看 系统 
三 商 提供 的 分 析 报 告 ， 报 告 中 指出 : 内存 突 然 由 800MB 闫 升 到 1.4GB， 
新 的 对 象 申 请 不 到 内 存 空 间 ， 于 是 出 现 OutOfMemory， 同 时 报告 中 还 列 
出 宕 机 时 刻 内 存 中 的 对 象 ， 其 中 SignInfo 类 的 对 象 就 有 400MB， 疯 子 ， 











绝对 是 狗 子 ! 报告 都 没有 看 听 ! 


问题 找到 了 ， 我 拉 郎 当 过 来 谈话 ,，“ 广 商 不 是 分 析出 原因 了 嘛 ， 人 
家 已 经 指出 SignInfo 类 的 对 象 占用 了 400MB 多 的 内 存 ， 这 是 怎么 回 事 ? ” 





“三 哥 ， 这 是 很 正常 的 ， 这 么 大 的 访问 量 ， 产 生出 这 么 多 的 SignInfo 
对 象 也 是 应 该 的 ， 内 存 中 有 这 么 多 对 象 并 不 表示 这 些 对 象 正在 被 使 用 
呀 ， 估 计 很 大 一 部 分 还 没有 被 回收 而 已 ， 垃 圾 回收 费 什 么 时 候 回 收 内 存 
中 的 对 象 这 是 不 确定 的 。 你 看 ， 并 发 200 多 个 ， 这 可 是 并 发 数量 .…...” 

















我 想 了 想 ， 也 确实 是 这 么 回 事 。 既 然 已 经 定位 是 内 存 中 对 象 太 多 ， 
那 就 应 该 想到 使 用 一 种 共 圣 的 技术 减少 对 象 数 量 ， 那 怎么 共 圣 呢 ? 


大 家 知道 ， 对 象 池 (Object Pool) 的 实现 有 很 多 开源 工具 ， 比 如 
Apache 的 commons- SO 我 们 暂时 还 用 不 到 
这 种 重量 级 的 工具 ， 我 们 自己 来 设计 一 个 共享 对 象 池 ， 需 要 实现 如 下 两 
个 功能 








e 容器 定义 


我 们 要 定义 一 个 池 容 费 ， 在 这 个 容 右 中 容纳 哪些 对 象 。 


e 提供 客户 端 访问 的 接口 


我 们 要 提供 一 个 接口 供 客户 端 访问 ， 池 中 有 可 用 对 象 时 ， 可 以 直接 


从 池 中 获得 ， 否 则 建立 一 个 新 的 对 象 ， 并 放置 到 池 中 。 


设计 思路 有 了 ， 那 我 们 池 中 对 象 的 标准 是 什么 呢 ? 你 想 想 看 ， 如 果 
你 把 所 有 的 对 象 都 放 到 池 中 ， 那 还 有 什么 意义 ?内 存 早 就 给 你 撑 爆 了 ! 
这 么 多 对 象 ， 必 然 有 一 些 相 同 的 属性 值 ， 如 几 十 万 SignInfo 对 象 中 ， 考 
试 科目 就 4 个 ， 考 试 地 点 也 就 是 30 多 个 ， 其 他 的 属性 则 是 每 个 对 象 都 不 
相同 的 ， 我 们 把 对 象 的 相同 属性 提取 出 来 ， 不 同 的 属性 在 系统 内 进行 赋 
值 处 理 ， 是 不 是 就 可 以 建立 一 个 池 了 ? 话 无 须 多 说 ， 我 们 以 类 图 来 表 
示 ， 如 图 28-2 所 示 。 
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+getter/setter( 


) 





图 28-2 增加 对 象 池 的 类 图 


做 一 个 很 小 的 改动 ， 增 加 了 一 个 子 类 ， 实 现 带 缓冲 池 的 对 象 建立 ， 
同时 在 工厂 类 上 增加 了 一 个 容器 对 象 HashMap， 保 存 池 中 的 所 有 对 象 。 
我 们 先 来 看 产品 子 类 ， 如 代码 清单 28-4 所 示 。 





代码 清单 28-4 带 对 象 池 的 报考 信息 


public class SignInfo4Pool extends SignInfo { 
// 定 义 一 个 对 象 池 提取 的 KEY 值 
private String key; 
// 构 造 函 数 获得 相同 标志 
public SignInfo4Pool(String _key)t{ 
this.key = _key; 





} 
public String getkey() { 
return key; 


} 

public void setkey(String key) { 
this.key = key; 

} 


很 简单 ， 就 是 增加 了 一 个 key 值 ， 为 什么 要 增加 key 值 ? 为 什么 要 使 
用 子 类 ， 而 不 在 SignInfo 类 上 做 修改 ? 好 ， 我 来 给 你 解释 为 什么 要 这 样 
做 ， 我 们 刚刚 已 经 分 析 了 所 有 的 SignInfo 对 象 都 有 一 些 共同 的 属性 ， 考 
试 科目 和 考试 地 点 ， 我 们 把 这 些 共性 提取 出 来 作为 所 有 对 象 的 外 部 状 
态 ， 在 这 个 对 象 池 中 一 个 具体 的 外 部 状态 只 有 一 个 对 象 。 按 照 这 个 设 
计 ， 我 们 定义 key 值 的 标准 为 : 考试 科目 + 考试 地 点 的 复合 字符 串 作为 唯 
一 的 池 对 象 标准 ， 也 就 是 说 在 对 象 池 中 ， 一 个 key 值 唯一 对 应 一 个 对 
象 。 








注意 “在 对 象 池 中 ， 对 象 一 旦 产生 ， 必 然 有 一 个 唯一 的 、 可 访问 
的 状态 标志 该 对 象 ， 而 且 池 中 的 对 象 声 明 周期 是 由 池 容 器 决定 ， 而 不 是 
由 使 用 者 决定 的 。 





你 可 能 马上 就 要 提出 了 ， 为 什么 不 建立 一 个 新 的 类 ， 包 含 subject 和 
location 两 个 属性 作为 外 部 状态 呢 ? 嗯 ， 这 是 一 个 办 法 ， 但 不 是 最 好 的 
办 法 ， 有 两 个 原因 : 


e 修改 的 工作 量 太 大 ， 增 加 的 这 个 类 由 谁 来 创建 呢 ?” 同 时 ， 
SignInfo 类 是 否 也 要 修改 呢 ? 你 不 可 能 让 两 段 相 同 的 POJO 程 序 同 时 出 现 
在 同一 模块 中 吧 ! 


e 性 能 问题 ， 我 们 会 在 扩展 模块 中 讲解 。 


说 了 这 么 多 ， 我 们 还 是 继续 来 看 程序 ， 工 厂 类 如 代码 清单 28-5 所 


代码 清单 28-5 带 对 象 池 的 工厂 类 


public class SignInfoFactory { 
// 池 容器 
private static HashMap<String,SignInfo> pool = new HashMap<S 
// 报 名 信息 的 对 象 工厂 
@Deprecated 
public static SignInfo(){ 
return new SignInfo(); 


} 
// 从 池 中 获得 对 象 
public static SignInfo getSignInfo(String Key){ 
// 设 置 返回 对 象 
SignInfo result = null; 
// 池 中 没有 该 对 象 ， 则 建立 ， 并 放 入 池 中 
if(!pool.containskey(key))t{ 
System,out.println(key +"---- 建 立 对 象 ， 并 放置 到 池 中 ") 
result = new SignInfo4Pool(key ) ; 
pool.put(key, result); 
}elsef{ 
result = pool.get(key); 
System,out.println(key +"--- 直 接 从 池 中 取得 ")， 




















return result,; 








方法 都 很 简单 ， 不 多 解释 。 读 者 需要 注意 一 点 的 是 @Deprecated 注 
解 ， 不 要 有 删除 投产 中 代码 的 念头 ， 如 果 方 法 或 类 确实 不 再 使 用 了 ， 增 
加 该 注解 ， 表 示 该 方法 或 类 已 经 过 时 ， 尽 量 不 要 再 使 用 了 ， 我 们 应 该 保 
持 历史 原貌 ， 同 时 也 有 助 于 版 本 向 下 兼容 ， 特 别 是 在 产品 级 研发 中 。 











我 们 再 来 看 看 客户 痢 是 如 何 调用 的 ， 如 代码 清单 28-6 所 示 。 


代码 清单 28-6 场景 类 


public class Client { 
public static void main(String[|] args) { 
// 初 始 化 对 象 池 
for(int i=0;i<4;i++){ 
String subject = "科目 " + 工 ; 
// 初 始 化 地 址 
for(int j=0;j<30;j++){ 
String key = subject + "考试 地 点 "+j; 
SignInfoFactory.getSignIinfo(key); 


i } 
SignInfo signInfo = SignInfoFactory .getSignInfo(" 科 目 1 考 
} 
} 
运行 结果 如 下 所 示 : 


科目 3 考试 地 点 25---- 建 立 对 象 ， 并 放置 到 池 中 
科目 3 考试 地 点 26---- 建 立 对 象 ， 并 放置 到 池 中 














科目 3 考试 地 点 27---- 建 立 对 象 ， 并 放置 到 池 中 


科目 3 考试 地 点 28---- 建 立 对 象 ， 并 放置 到 池 中 








科目 3 考试 地 点 29---- 建 立 对 象 ， 并 放置 到 池 中 





科目 1 考试 地 点 1--- 直 接 从 池 中 取得 











前 面 还 有 很 多 的 对 象 创建 提示 语句 ， 不 再 复制 。 通 过 这 样 的 改造 
后 ， 我 们 想 想 内 存 中 有 多 少 个 SignInfo 对 象 ? 是 的 ， 最 多 120 个 对 象 ， 相 
比 之 前 几 万 个 SignInfo 对 象 优化 了 非常 多 。 细 心 的 读者 可 能 注意 到 了 
SignInfo4Pool 类 基本 上 没有 跑 出 我 们 的 视线 范围 ， 仅 仅 在 工矿 方法 中 使 
用 到 了 ， 尽 量 缩小 变更 引起 的 风险 ， 想 想 看 我 们 的 改动 是 不 是 很 小 ， 只 
要 在 展示 层 中 拼 一 个 字符 串 ， 然 后 传递 到 工厂 方法 中 就 可 以 了 。 





通过 这 样 的 改造 后 ， 第 三 天 系统 运行 得 非常 稳定 ，CPU 占 用 率 也 下 
降 了 ， 而 且 以 后 再 也 没有 出 现 类 似 问 题 ， 这 就 是 胖 元 模式 的 功 荔 。 





28.2 怪 元 模式 的 定义 





享 元 模式 (Flyweight Pattern〉 是 池 技 术 的 重要 实现 方式 ， 其 定义 如 
下 : Use sharing to support large numbers of fine-grained objects efficiently. 


(使 用 共 圣 对 象 可 有 效 地 支持 大 量 的 细 粒 度 的 对 象 。 








译 元 模式 的 定义 为 我 们 提出 了 两 个 要 求 : 细 粒 度 的 对 象 和 共享 对 
象 。 我 们 知道 分 配 太 多 的 对 象 到 应 用 程序 中 将 有 损 程序 的 性 能 ， 同 时 还 
容易 造成 内 存 流 出 ， 那 怎么 避免 呢 ? 就 是 胖 元 模式 提 到 的 共享 技术 。 我 
们 先 来 了 解 一 下 对 象 的 内 部 状态 和 外 部 状态 。 





要 求 细 粒度 对 象 ， 那 么 不 可 避免 地 使 得 对 象 数量 多 且 性 质 相 近 ， 那 
我 们 就 将 这 些 对 象 的 信息 分 为 两 个 部 分 : 内 部 状态 (intrinsic) 与 外 部 


状态 〈extrinsic) 。 


e 内 部 状态 








内 部 状态 是 对 象 可 共享 出 来 的 信息 ， 存 储 在 享 元 对 象 内 部 并 且 不 会 
随 环 境 改 变 而 改变 ， 如 我 们 例子 中 的 id、postAddress 等 ， 它 们 可 以 作为 
一 个 对 象 的 动态 附加 信息 ， 不 必 直 接 储存 在 具体 某 个 对 象 中 ， 属 于 可 以 
共享 的 部 分 











e 外 部 状态 








外 部 状态 是 对 象 得 以 依赖 的 一 个 标记 ， 是 随 环境 改变 而 改变 的 、 不 
可 以 共 圣 的 状态 ， 如 我 们 例子 中 的 考试 科目 + 考试 地 点 复合 字符 串 ， 它 
古 一 批 对 象 的 统一 标识 ， 是 唯一 的 一 个 索引 值 。 





有 了 对 象 的 两 个 状态 ， 我 们 就 可 以 来 看 至 元 模式 的 通用 类 图 ， 如 图 


28-3 所 示 。 
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图 28-3 享 元 模式 的 通用 类 图 


类 图 也 很 简单 ， 我 们 先 来 看 我 们 享 元 模式 角色 名 称 。 
e Flyweight 一 一 抽象 享 元 角色 


它 简 单 地 说 束 是 一 个 产品 的 抽象 类 ， 同 时 定义 出 对 象 的 外 部 状态 和 
内 部 状态 的 接口 或 实现 。 





e ConcreteFlyweight 一 一 具体 享 元 角色 
具体 的 一 个 产品 类 ， 实 现 抽 象 角色 定义 的 业务 。 访 角色 中 需要 注意 


的 是 内 部 状态 处 理应 该 与 环境 无 天 ， 不 应 该 出 现 一 个 操作 改变 了 内 部 状 
态 ， 同 时 修改 了 外 部 状态 ， 这 是 绝对 不 允许 的 。 











® unsharedConcreteFlyweight 不 可 共享 的 享 元 角色 





不 存在 外 部 状态 或 者 安全 要 求 〈 如 线程 安全 ) 不 能 够 使 用 共 至 技术 
的 对 象 ， 该 对 象 一 般 不 会 出 现在 至 元 工厂 中 。 





e@ FlyweightFactory 一 一 享 元 工厂 


职 贡 非常 简单 ， 就 是 构造 一 个 池 容 句 ， 同 时 提供 从 池 中 获得 对 象 的 
太 , 
诗 元 模式 的 目的 在 于 运用 共有 至 拉 术 ， 使 得 一 些 细 粒度 的 对 象 可 以 共 


译 ， 我 们 的 设计 确实 也 应 该 这 样 ， 多 使 用 细 粒 度 的 对 象 ， 便 于 重用 或 重 
构 。 我 来 看 至 元 模式 的 通用 代码 ， 先 看 抽象 至 元 角色 ， 如 代码 清单 28-7 





代码 清单 28-7 抽象 享 元 角色 


public abstract class Flyweight { 
// 内 部 状态 
private String intrinsic; 
// 外 部 状态 
protected final String EXxtrinsic 








// 要 求 享 元 角色 必须 接受 外 部 状态 
public Flyweight(String _Extrinsic)t{ 
this.Extrinsic = _Extrinsic; 


} 

// 定 义 业务 操作 

public abstract void operate( ) ; 
// 内 部 状态 的 getter/setter 

public String getIntrinsic() { 
return intrinsic; 





public void setIntrinsic(String intrinsic) { 
this.intrinsic = intrinsic,; 
} 





抽象 享 元 角色 一 般 为 抽象 类 ， 在 实际 项 目 中 ， 一 般 是 一 个 实现 类 ， 
它 是 描述 一 类 事物 的 方法 。 在 抽象 角色 中 ， 一 般 需 要 把 外 部 状态 和 内 部 
状态 (当然 了 ， 可 以 没有 内 部 状态 ， 只 有 行为 也 是 可 以 的 ) 定义 出 来 ， 
避免 子 类 的 随意 扩展 。 我 们 再 来 看 具体 的 享 元 角色 ， 如 代码 清单 28-8 所 


帮 \。 


代码 清单 28-8 具体 享 元 角色 


public class ConcreteFlyweight1 extends Flyweight{ 
// 接 受 外 部 状态 
public ConcreteFlyweight1i(String _Extrinsic)t 
super(_Extrinsic); 


// 根 据 外 部 状态 进行 逻辑 处 理 

public void operate( ){ 
// 业 务 逻 辑 

} 


public class ConcreteFlyweight2 extends Flyweight{ 
// 接 受 外 部 状态 
public ConcreteFlyweight2(String _Extrinsic)t 
super(_Extrinsic); 


3 
// 根 据 外 部 状态 进行 逻辑 处 理 


public void operate(){ 













































































// 业 务 逻 辑 





很 简单 ， 实 现 目 己 的 业务 逻辑 ， 然 后 接收 外 部 状态 ， 以 便 内 部 业 
务 逻 辑 对 外 部 状态 的 依赖 。 注 意 ， 我 们 在 抽象 至 元 中 对 外 部 状态 加 上 了 
final 关 键 字 ， 防 止 意外 产生 ， 什 么 意外 ? 获得 了 一 个 外 部 状态 ， 然 后 无 
意 修 改 了 一 下 ， 池 就 混乱 了 ! 











注意 “在 程序 开发 中 ， 确 认 只 需要 一 次 赋值 的 属性 则 设置 为 final 类 
型 ， 避 免 无 意 修 改 导 致 还 辑 混乱 ， 特 别 是 Session 级 的 种 量 或 变量 。 





我 们 继续 看 人 享 元 工厂 ， 如 代码 清单 28-9 所 示 。 


代码 清单 28-9 享 元 工厂 


public class FlyweightFactory { 
// 定 义 一 个 池 容 器 
private static HashMap<String,Flyweight> pool= new HashMap< 





// 享 元 工厂 

public static Flyweight getFlyweight(String Extrinsic)t 
// 需 要 返回 的 对 象 
Flyweight flyweight = null; 
// 在 池 中 没有 该 对 象 





if(pool.containsKey(Extrinsic))t 
flyweight = pool.get(Extrinsic); 
}elsef 
// 根 据 外 部 状态 创建 享 元 对 象 
flyweight = new ConcreteFlyweight1i(Extrinsic 
// 放 置 到 池 中 
pool.put(Extrinsic, flyweight); 





return flyweight; 


28.3 至 元 模式 的 应 用 


28.3.1 孚 元 模式 的 优点 和 缺点 


译 元 模式 是 一 个 非 第 简单 的 模式 ， 它 可 以 大 大 减少 应 用 程序 创建 的 
对 象 ， 降 低 程序 内 存 的 占用 ， 增 强 程序 的 性 能 ， 但 它 同 时 也 提高 了 系统 
复杂 性 ， 需 要 分 离 出 外 部 状态 和 内 部 状态 ， 而 且 外 部 状态 具有 固化 特 
性 ， 不 应 该 随 内 部 状态 改变 而 改变 ， 否 则 导致 系统 的 逻辑 混乱 。 





28.3.2 享 元 模式 的 使 用 场景 





在 如 下 场景 中 则 可 以 选择 使 用 至 元 模式 。 


e 系统 中 存在 大 量 的 相似 对 象 。 


e 细 粒 度 的 对 象 都 具备 较 接 近 的 外 部 状态 ， 而 且 内 部 状态 与 环境 无 
关 ， 也 惑 是 说 对 象 没 有 特定 身份 。 


e 需要 绥 冲 池 的 场景 。 


28.4 至 元 模式 的 扩展 


28.4.1 线程 安全 的 问题 





线程 安全 是 一 个 老生 常 谈 的 话题 ， 只 要 使 用 Java 开 发 都 会 遇 到 这 个 
问题 ， 我 们 之 所 以 要 在 今天 的 享 元 模式 中 提 到 该 问题 ， 是 因为 该 模式 有 
太 大 的 几率 发 生 线程 不 安全 ， 为 什么 呢 ? 








我 们 还 以 报考 系统 为 例 来 说 明 这 个 问题 。 大 家 有 没有 想 过 ， 为 什么 
要 以 考试 科目 + 考试 地 点 作为 外 部 状态 呢 ? 为 什么 不 能 以 考试 科目 或 者 
考试 地 点 作为 外 部 状态 呢 ? 这 样 池 中 的 对 象 会 更 少 ! 可 以 ! 完全 可 以 ! 
我 们 把 程序 以 考试 科目 为 外 部 状态 ， 把 享 元 工厂 稍 作 修改 ， 如 代码 清单 
28-10 上 所 示 。 


代码 清单 28-10 报考 信息 工厂 


public class SignInfoFactory { 
// 池 容器 
private static HashMap<String,SignInfo> pool = new HashMap<S 
// 从 池 中 获得 对 象 
public static SignInfo getSignInfo(String key)t{ 
// 设 置 返回 对 象 
SignInfo result = null; 
// 池 中 没有 该 对 象 ， 则 建立 ， 并 放 入 池 中 
if(!pool.containskey(key))t{ 
result = new SignIinfo(); 
pool.put(key, result); 
}elsef 
result = pool.get(key); 
} 








return result,; 


下 面 做 很 小 的 改动 ， 只 修改 了 黑色 字体 部 分 。 为 了 展示 多 线程 的 情 
况 ， 我 们 写 一 个 多 线程 的 类 ， 如 代码 清单 28-11 所 示 。 


代码 清单 28-11 多 线程 场景 


public class MultiThread extends Thread { 
private SignInfo signInfo; 
public MultiThread(SignIinfo _signInfo)t{ 
this.signInfo = _signInfo; 


public void run(){ 
if(!signIinfo.getIid().equals(signIinfo.getLocation())) 
System.out .println(" 编 号 : "+SignInfo,getId()) 
System.out.println(" 考 试 地 址 : "+signInfo.getLo 
System.out .println( "线程 不 安全 了 ! ")， 











在 run 方 法 中 判断 特殊 值 ， 检 查 是 否 是 线程 安全 ， 我 们 来 看 看 场景 
类 ， 如 代码 清单 28-12 所 示 。 





代码 清单 28-12 场景 类 


public class Client { 
public static void main(String[|] args) { 
// 在 对 象 池 中 初始 化 4 个 对 象 
SignInfoFactory.getSignInfo(" 科 目 1")， 
SignInfoFactory.getSignInfo(" 科 目 2"); 
SignInfoFactory.getSignInfo(" 科 目 3")， 
SignInfoFactory.getSignInfo(" 科 目 4")，; 
// 取 得 对 象 
SignInfo signInfo = SignInfoFactory.getSignInfo(" 科 目 
while(true)t{ 
signInfo.setIid("ZhangSan"); 
signInfo.setLocation("ZhangSan"); 





(new MultiThread(signInfo)), start(); 
signIinfo,.setIid("LiSi" ); 
signInfo.setLocation("LiSi"); 

(new MultiThread(signIinfo)).start(); 


模拟 实际 的 多 线程 情况 ， 在 对 象 池 中 我 们 保留 4 个 对 象 ， 然 后 启动 
N 多 个 线程 来 模拟 ， 我 们 蕊 上 束 看 到 如 下 的 提示: 

















编号 : LiSi 
考试 地 址 : ZhangSan 


线程 不 安全 了 ! 





看 看 ， 线 程 不 安全 了 吧 ， 这 是 正常 的 ， 设 置 的 至 元 对 象 数量 太 少 ， 
导致 每 个 线程 都 到 对 象 池 中 获得 对 象 ， 然 后 部 去 修改 其 属性 ， 于 是 就 出 
现 一 些 不 和 谐 数 据 。 只 要 使 用 Java 开 发 ， 线 程 问 题 是 不 可 避免 的 ， 那 我 
们 怎么 去 避免 这 个 问题 呢 ? 享 元 模式 是 让 我 们 使 用 共享 技术 ， 而 Java 的 
多 线程 又 有 如 此 问题 ， 该 如 何 设计 呢 ? 没 什么 可 以 参考 的 标准 ， 只 有 依 
徘 经 验 ， 在 需要 的 地 方 考虑 一 下 线程 安全 ， 在 大 部 分 的 场景 下 都 不 用 考 
虑 。 我 们 在 使 用 享 元 模式 时 ， 对 象 池 中 的 享 元 对 象 尽 量 多 ， 多 到 足够 满 
足 业 务 为 止 。 























28.4.2 性 能 平衡 


尽量 使 用 Java 基 本 类 型 作为 外 部 状态 。 在 报考 系统 中 ， 我 们 不 考虑 


系统 的 修改 风险 ， 完 全 可 以 重新 建立 一 个 类 作为 外 部 状态 ， 因 为 这 才 完 
全 符合 面向 对 象 编程 的 理念 。 好 ， 我 们 实现 处 理 ， 先 看 类 图 ， 如 图 28-4 
所 示 。 





Signlnfo 


-String 1d 
| -Extrinsic State state 
-getLocation 


+getter/setter() 


图 28-4 类 作为 外 部 状态 


我 们 首先 来 看 ExtrinsicState 外 部 状态 类 ， 如 代码 清单 28-13 所 示 。 


代码 清单 28-13 外 部 状态 类 


public class ExtrinsicState { 
// 考 试 科目 
private String subject; 
// 考 试 地 点 
private String location; 
public String getSubject() { 
return subject; 


public void setSubject(String subject) { 
this.subject = subject; 


public String getLocation() { 
return location; 


public void setLocation(String location) { 
this.1location = location; 


@Override 
public boolean equals(Object obj)t{ 
if(obj instanceof ExtrinsicState)t{ 
ExtrinsicState state = (ExtrinsicState)obj; 
return state.getLocation().equals(location) && 


return false; 
@Override 


public int hashcode(){ 
return subject.hashCode() + location.hashCode(); 
} 








注意 ， 一 定 要 有 履 写 equals 和 hashCode 方 法 ， 否 则 它 作 为 HashMap 中 
的 key 值 是 根本 没有 意义 的 ， 只 有 hashCode 值 相等 ， 并 且 equals 返 回 结果 
为 tue， 两 个 对 象 才 相等 ， 也 只 有 在 这 种 情况 下 才 有 可 能 从 对 象 池 中 查 
找 获 得 对 象 。 








注意 如果 把 一 个 对 象 作为 Map 类 的 键 值 ， 一 定 要 确保 重 写 了 
equals 和 hashCode 方 法 ， 人 否则 会 出 现 通 过 键 值 搜索 失败 的 情况 ， 例 如 
map.get(object)、map.contains(object) 等 会 返回 失败 的 结果 。 





SignInfo 的 修改 较 小 ， 仅 在 SignInfo 中 引入 该 ExtrinsicState 外 部 状态 
对 象 ， 在 此 不 再 歼 述 。 我 们 再 来 看 享 元 工厂 ， 它 是 以 ExtrinsicState 类 作 
为 外 部 状态 ， 如 代码 清单 28-14 所 示 。 





代码 清单 28-14 享 元 工厂 


public class SignInfoFactory { 








// 池 容器 
private static HashMap<ExtrinsicState,SignIinfo> pool = new H 
// 从 池 中 获得 对 象 
public static SignInfo getSignInfo(ExtrinsicState key)t{ 
// 设 置 返回 对 象 
SignInfo result = null; 
// 池 中 没有 该 对 象 ， 则 建立 ， 并 放 入 池 中 
if(!pool.containskey(key))t{ 
result = new SignInfo(); 
pool.put(key, result); 
}elsef 
result = pool.get(key); 
} 
return result,; 
} 


重点 是 看 看 我 们 的 场景 类 ， 我 们 来 测试 一 下 性 能 差异 ， 如 代码 清单 
28-15 所 示 。 


代码 清单 28-15 场景 类 


public class Client { 
public static void main(String[] args) { 
// 初 始 化 对 象 池 
ExtrinsicState State1 = new ExtrinsicState() 
state1.setSubject(" 科 目 1"); 
state1.setLocation(" 上 海 " ) 
SignInfoFactory.getSignIinfo(state1); 
ExtrinsicState state2 = new ExtrinsicState(); 
state2,setSubject(" 科 目 1"); 
state2.setLocation(" 上 海 ")，; 
// 计 算 执行 1200 万 次 需要 的 时 间 
long currentTime = System.currentTimeMillis(); 
for(int i=0;i<1000000;i++)f{ 
SignInfoFactory.getSignIinfo(state2); 








long tailTime = System.currentTimeMillis(); 
System.out.println(" 执 行 时 间 : "+(tailTime - currentTin 


运行 结果 如 下 所 示 : 
执行 时 间 : 172 ms 


同样 ， 我 们 看 看 以 String 类 型 作为 外 部 状态 的 运行 情况 ， 如 代码 清 
单 28-16 所 示 。 


代码 清单 28-16 场景 类 


public class Client { 
public static void main(String[] args) { 
String key1 = "科目 1 上 海 "， 
String key2 = "科目 1 上 海 "， 
// 初 始 化 对 象 池 
SignInfoFactory.getSignIinfo(key1); 
// 计 算 执 行 10 万 次 需要 的 时 间 
long currentTime = System.currentTimeMillis(); 
for(int i=0;i<10000000;i++)f{ 
SignInfoFactory.getSignInfo(key2); 








long tailTime = System.currentTimeMillis(); 
System.out .println(" 执 行 时 间 : "+(tailTime - currentTin 


一 


运行 结果 如 下 所 示 : 
执行 时 间 : 78 ms 


看 到 没 ? 一 半 的 效率 ， 这 还 是 非常 简单 的 享 元 对 象 ， 看 看 我 们 重 写 
的 equals 方 法 和 hashCode 方 法 ， 这 段 代 码 是 必须 实现 的 ， 如 果 比 较 复 
杂 ， 这 个 时 间 差 异 会 更 大 。 


各 位 ， 想 想 看 ， 使 用 上 自己 编写 的 类 作为 外 部 状态 ， 必 须 窗 写 equals 
方法 和 hashCode 方 法 ， 而 且 执 行 效率 还 比较 低 ， 这 种 吃力 不 讨好 的 事情 
最 好 别 做 ， 外 部 状态 最 好 以 Java 的 基本 类 型 作为 标志 ， 如 String、int 
等 ， 可 以 大 幅 地 提升 效率 。 











28.5 最 佳 实践 





Flyweight 是 拳击 比赛 中 的 特 用 名 词 ， 意 思 是 “ 特 轻 量 级 ”， 指 的 是 51 
公斤 级 比赛 ， 用 到 设计 模式 中 是 指 我 们 的 类 要 轻 量 级 ， 粒 上 度 要 小 ， 这 才 

它 要 表达 的 意思 。 粒 上 度 小 了 ， 带 来 的 问题 就 是 对 象 太 多 ， 那 束 用 共 吾 
技术 来 解决 。 


享 元 模式 在 Java API 中 也 是 随处 可 见 ， 如 这 样 的 程序 就 是 一 个 很 好 
的 例子 ， 如 代码 清单 28-17 所 示 。 





代码 清单 28-17 API 中 的 享 元 模式 


public class Test { 

public static void main(String[] args) { 
String str1 = "和 谐 "， 
String str2 = "社会 " ; 
String str3 = "和 谐 社 会 "， 
String str4; 
Str4 = stri + str2,; 
System.out.println(str3 == str4); 
str4 = (stri + str2).intern(); 
System.out.println(str3 == str4); 


看 看 Java 的 帮助 文件 中 String 类 的 intern 方 法 。 如 果 是 String 的 对 象 池 
中 有 该 类 型 的 值 ， 则 直接 返回 对 象 池 中 的 对 象 ， 那 当然 相等 了 。 





需要 说 明 一 下 的 是 ， 昌 然 可 以 使 用 至 元 模式 可 以 实现 对 象 池 ， 但 是 


这 两 者 还 是 有 比较 大 的 差异 ， 对 象 池 着 重 在 对 象 的 复 用 上 ， 池 中 的 每 个 
对 象 是 可 答 换 的 ， 从 同一 个 池 中 获得 A 对 象 和 B 对 象 对 客户 端 来 说 是 完 
全 相同 的 ， 它 主要 解决 复 用 ， 而 至 元 模式 在 主要 解决 的 对 象 的 共 至 问 
题 ， 如 何 建 立 多 个 可 共享 的 细 粒 上 度 对 象 则 是 其 关注 的 重点 。 








第 29 间 ”桥梁 模式 
29.1 我 有 一 个 梦想 ...... 


我 们 每 个 人 都 有 理想 ， 但 不 要 只 是 空想 ， 理 想 是 要 靠 今 天 的 拼搏 来 
实现 的 。 今 天 咱们 就 来 谈 谈 自 己 的 理想 ， 如 希望 成 为 一 个 富 倘 ， 身 价 过 
亿 ， 有 了 两 家 大 公司 ， 一 家 是 房地产 公司 ， 男 一 家 是 服装 制造 公司 。 这 两 
家 公司 都 很 赚钱 ， 天 天 帮 你 累积 财富 。 其 实 你 并 不 关心 公司 的 类 型 ， 你 
关心 的 是 它们 是 不 是 在 赚钱 ， 赚 了 多 少 ， 这 才 是 你 关注 的 。 商 人 嘛 ， 唯 
利 是 图 是 其 本 性 ， 偷 税 漏税 是 方法 ， 其 上 瞒 下 、 压 榨 员 工 血 汗 是 常用 的 
手段 ， 先 用 类 图 表示 一 下 这 两 个 公司 ， 如 图 29-1 所 示 。 















Client 


+Vold makeMoney() 
tvoid producel() 
+void selll) 


图 29-1 人 铬 利 模 式 的 类 图 


类 图 很 简单 ， 声 明了 一 个 Corp 抽 象 类 ， 定 义 一 个 公司 的 抽象 模型 ， 
公司 首要 是 赚钱 的 ， 做 义务 或 善举 那 也 是 有 背后 利益 文 撑 的 ， 还 是 赞成 
的 源 代 码 ， 如 代码 清 蛙 29-1 所 示 。 


代码 清单 29-1 抽象 公司 


public abstract class Corp { 
/* 








* 如 果 是 公司 就 应 该 有 生产 ， 不 管 是 软件 公司 还 是 制造 业 公司 
* 每 家 公司 生产 的 东西 都 不 一 样 ， 所 以 由 实现 类 来 完成 


protected abstract void produce(); 
类 
































* 有 产品 了 ， 那 肯定 要 销售 啊 ， 不 销售 公司 怎么 生存 
*/ 


protected abstract void sell(); 


// 公 司 是 干什么 的 ?赚钱 的 

public void makeMoney(){ 
// 每 个 公司 都 是 一 样 ， 先 生产 
this.produce( ); 
// 然 后 销售 
this. sell(); 








怎么 这 是 模板 方法 模式 啊 ? 是 的 ， 这 是 个 引子 ， 请 继续 往 下 看 。 合 
适 的 方法 存在 合适 的 类 中 ， 这 个 基本 上 是 每 本 Java 基 础 书 上 都 会 讲 的 ， 
但 是 到 实际 的 项 目 中 应 用 的 时 候 就 不 是 这 么 回 事 儿 了。 我们 继续 看 两 个 
实现 类 是 如 何 实现 的 ， 先 看 HouseCorp 类 ， 这 是 最 赚钱 的 公司 ， 如 代码 
清单 29-2 所 示 。 








代码 清单 29-2 房地产 公司 


public class HouseCorp extends Corp { 
// 房 地 产 公司 盖 房 子 
protected void produce() { 
System,.out,.println(" 房 地 产 公 司 盖 房 子 . , ,")， 


// 房 地 产 公司 卖 房子 ， 自 己 住 那 可 不 赚钱 
protected void sell() { 
System.out.println(" 房 地 产 公司 出 售 房子 ..."); 


} 
// 房 地 产 公司 很 High 了 ， 赚 钱 ， 计 算 利润 
or void makeMoney( ){ 
super .makeMoney( ); 
System,out.println(" 房 地 产 公司 赚 大 钱 了 ,.."); 














房地产 公司 按照 正规 翻译 来 说 应 该 是 realty corp， 这 个 是 比较 准确 
的 翻译 ， 但 是 我 问 你 把 房地产 公司 翻译 成 英文 ， 你 的 第 一 反应 是 什么 ? 
house corp! 这 是 中 式 喘 语 。 我 们 再 来 看 服装 公司 ， 虽 然 不 景气 ， 但 好 








图 也 是 赚钱 的 ， 如 代码 清单 29-3 所 示 。 


代码 清单 29-3 服装 公司 


public class ClothesCorp extends Corp { 
// 服 装 公司 生产 的 就 是 衣服 了 


protected void produce() { 


System.out,printlLn(" 服 装 公 司 生 产 衣 服 . ， 
} 
// 服 装 公司 卖 服装 ， 可 只 卖 服装 ， 不 卖 罕 衣服 的 模特 
售 衣服 , ， 


protected void sell() { 
System,out,.printLn(" 服 装 公司 出 


} 
// 服 装 公司 不 景气 ， 但 怎么 说 也 是 赚钱 行业 
public void makeMoney(){ 

super .makeMoney( ) ; 








System.out.println(" 服 装 公 司 赚 小 钱 .. 


两 个 公司 部 有 了 ， 那 肯定 有 人 会 关心 两 个 公司 的 运 





本 


i 


营 情 况 。 你 也 


知道 它 是 生产 什么 的 ， 以 及 赚 多 少 钱 吧 。 通 过 场景 类 来 进行 模拟 ， 如 代 


码 清 单 29-4 所 示 。 


代码 清单 29-4 场景 类 


public class Client { 


public static void main(String[] args) { 
System.out.println("------- 房地产 公司 是 这 样 运行 的 ------- 


// 先 找到 我 的 公司 





HouseCorp houseCorp =new HouseCorp(); 














// 看 我 怎么 挣 钱 
houseCorp.makeMoney( ); 
System.out.println("\n"); 





System.out.printJln("------- 服装 公司 是 这 样 运行 的 ------- 由 
CJlothesCorp clothesCorp = new Clothescorp(); 


clothesCorp.makeMoney( ) ， 





这 段 代码 很 简单 ， 运 行 结 果 如 下 所 示 : 


Ss 房地产 公司 是 这 样 运行 的 ------ 














房地产 公司 盖 房 站 


房地产 公司 出 售 房子 .… 











房地产 公司 赚 大 钱 了 .… 


Eo 服装 公司 是 这 样 运行 的 ------ 











服装 公司 生产 衣服 … 
服 疼 公司 出 售 衣服 .… 

















服装 公司 赚 小 钱 … 











上 述 代 码 完全 可 以 描述 我 现在 的 公司 ， 但 是 你 要 知道 万 物 都 是 运动 
的 ， 你 要 用 运动 的 眼光 看 问题 ， 公 司 才 会 及 展 .…... 终 于 有 一 天 你 觉得 赚 
钱 速度 太 慢 ， 于 是 你 上 下 巩 通 ， 左 右 打 关系 ， 终 于 开辟 了 一 条 赚钱 
的 “ 康 庄 大 道 ?: 生产 山寨 产 品 ! 什么 产品 呢 ? 即 市 场 上 什么 牌子 的 东西 
火爆 我 生产 什么 牌子 的 东西 ， 不 省 是 打火机 还 是 电脑 ， 只 要 它 火 爆 ， 我 
就 生产 ， 赚 过 了 高 峰 期 就 换个 产品 ， 打 一 枪 换 一 个 牌子 ， 不 承担 售后 成 
本 、 也 不 担心 销路 问题 ， 我 只 要 正品 的 十 分 之 一 的 价格 ， 你 买 不 买 ? 哈 
哈 ， 赚 钱 啊 ! 














企业 的 方 同 定 下 来 了 ， 通 过 调查 ， 苹 果 公 司 的 Pod 系 列 产品 比较 火 
爆 ， 那 中 就 生产 这 个 ， 把 服装 三 改 成 iPod 生产 广 ， 看 类 图 的 变化 ， 如 图 


29-2 所 示 O 


+vold makeMoney() 
+void producel() 
+void sell() 





图 29-2 服装 公司 改头换面 后 的 类 图 


的 实现 ， 如 代码 清单 29-5 所 示 。 


代码 清单 29-5 iPod 山寨 公司 


public class IPodCorp extends Corp { 
// 我 开始 生产 iPod 了 
protected void produce() { 
System.out.println(" 我 生产 iPod..."); 





} 

// 山 寨 的 jPod 很 畅销 ， 便 宜 嘛 

protected void sell() { 
System.out.println("iPod 畅 销 ,..")， 


} 

// 狂 赚钱 

public void makeMoney(){ 
super .makeMoney( )， 
System,out.printlLn(" 我 赚钱 呀 ,, .7")，) 











服装 工厂 改 成 了 电子 工厂 ， 你 这 个 董事 长 还 是 要 去 看 看 到 后生 产 什 
么 的 ， 场 景 类 如 代码 清单 29-6 所 示 。 


代码 清单 29-6 场景 类 


public class Client { 
public static void main(String[|] args) { 

System,out,println("------- 房地产 公司 是 按 这 样 运行 的 - ---- 
// 先 找到 我 的 公司 
HouseCorp houseCorp =new HouseCorp(); 
// 看 我 怎么 挣 钱 
houseCorp.makeMoney( ); 
System.out.println("\n"); 
System.out.println("------- 山寨 公司 是 按 这 样 运行 的 - - - - - -- 
IPodCorp iPodCorp = new IPodCorp(); 
iPodCorp.makeMoney( ); 























确实 ， 只 用 修改 了 黑色 字体 这 几 句 话 ， 服 装 三 就 开始 变 成 山寨 iPod 
生产 车 间 ， 然 后 你 束 看 着 你 的 财富 在 积 毗 。 山 笃 的 东西 不 需要 特别 的 销 
售 渠道 (正品 到 哪里 我 就 到 哪里 )，， 不 需要 维修 成 本 (大 不 了 给 你 换 
个 ， 你 还 想 怎 么 样 ， 过 了 高 峰 期 我 束 改 头 换 面 了 ， 你 找 谁 维修 去 ? 投 
诉 ? 投诉 谁 呢 ?) ， 不 承担 广告 成 本 《〈 正 品 在 打 广告 ， 我 还 需要 吗 ? 需 
要 吗 ? ) ， 但 是 也 有 犯愁 的 时 候 ， 这 是 一 个 山寨 工 片 ， 要 及 时 地 生产 出 
市 场 上 流行 的 产品 ， 转 型 要 快 ， 要 有 灵活， 今天 从 生产 iPod 转 为 生产 MP4， 
明天 再 转 为 生产 上 网 本 ， 这 都 需要 灵活 的 变化 ， 不 要 限制 得 太 死 ! 那 问 
题 来 了 ， 每 次 我 的 厂房 ， 我 的 工人 ， 我 的 设备 都 在 ， 不 可 能 每 次 我 换个 
山 罕 产品 三 子 束 彻 底 不 要 了 。 这 不 行 ， 成 本 不 蜗 了 点 ， 那 怎么 办 ? 





Thinking,Thinking...I got an ideal!〈 跳 跳 虎 语 ) ， 既 然 产 品 和 工厂 绑 
得 太 死 ， 那 我 就 给 你 来 松 松 ， 改 变 设计 ， 如 图 29-3 所 示 。 


= 有 和 ~ 
orp 


-Product product 
+void beProducted() 


+Corp(Product product) +void beSelled() 
+void make Money() 

























上 === 





FQ 
图 29-3 使 用 快速 变化 的 类 图 


公司 和 产品 之 间 建 立 关 联 关系 ， 可 以 彻底 解决 以 后 山寨 公司 生产 产 
品 的 问题 ， 工 厂 想 换 产 品 ? 太 容 易 了 ! 看 程序 说 话 ， 先 看 Product 抽 象 
类 ， 如 代码 清单 29-7 所 示 。 


代码 清单 29-7 抽象 产品 类 


public abstract class Product { 
// 表 管 是 什么 产品 它 总 要 能 被 生产 出 来 
public abstract void beProducted() ， 
// 生 产 出 来 的 东西 ， 一 定 要 销售 出 去 ， 和 否则 亏本 
public abstract void beSelled(); 























-> 


简单 ! 忒 简单 了 ! House 产 品类 如 代码 清单 29-8 所 示 。 


代码 清单 29-8 房子 


public class House extends Product { 
// 豆 腐 漆 就 豆腐 酒吧 ， 好 未 也 是 房子 
public void beProducted() { 














System.out.println(" 生 产 出 的 房子 是 这 样 的 . ， 





// 虽 然 是 豆腐 漆 ， 也 是 能 够 销售 出 去 的 
public void beSelled() { 


$ 











System,out.println(" 生 产 出 的 房子 卖 出 去 了 , ， 


汪 


J 


既然 是 产品 类 ， 那 肯定 有 两 种 行为 要 存在 : 被 生产 和 被 销售 ， 人 否则 
就 不 能 称 为 产品 了 。 我 们 再 来 看 记 od 产 品类 ， 如 代码 清单 29-9 所 示 。 


代码 清单 29-9 iPod 产品 


public class IPod extends Product { 
public void beProducted() { 





System,.out.println(" 生 产 出 的 iPod 是 这 样 的 . ， 


} 
public void beSelled() { 


} 


System.out.println(" 生 产 出 的 jPod 卖 出 去 了 ..." 


产品 是 由 公司 生产 出 来 的 ， 我 们 来 看 公司 Corp 抽 象 类 ， 


29-10 所 示 。 


代码 清单 29-10 抽象 公司 类 


public abstract class Corp { 

/7 定义 一 个 抽象 的 产品 对 象 不 知道 具体 是 什么 产品 

private Product product 

// 构 造 函 数 ， 由 子 类 定义 传递 具体 的 产品 进来 

public Corp(Product product)t{ 
this.product = product; 


} 
// 公 司 是 干什么 的 ? 赚钱 的 ! 
public void makeMoney( ){ 
// 每 家 公司 都 是 一 样 ， 先 生产 


























A 


); 


如 代码 清单 


this.product.beProducted( ); 
// 然 后 销售 
this.product.beSelled( ); 








这 里 多 了 个 有 参 构 造 ， 其 目的 是 要 继承 的 子 类 都 必 选 重 写 自己 的 有 
参 构 造 函 数 ， 把 产品 类 传递 进来 ， 再 看 子 类 HouseCorp 的 实现 ， 如 代码 


清单 29-11 所 示 O 


代码 清单 29-11 房地产 公司 


public class HouseCorp extends Corp { 
// 定 义 传递 一 个 House 产 品 进来 
public HouseCorp(House house)t 
super (house); 


} 

// 房 地 产 公司 很 High 了 ， 赚 钱 ， 计 算 利润 

public void makeMoney(){ 
super .makeMoney( ); 
System.out.println(" 房 地 产 公司 赚 大 钱 了 ..."); 





理解 上 没有 多 少 难度 ， 不 多 说 ， 继 续 看 山寨 公司 的 实现 ， 如 代码 清 
单 29-12 所 示 。 


代码 清单 29-12 山寨 公司 


public class ShanzhaiCorp extends Corp { 
// 产 什么 产品 ， 不 知道 ， 等 被 调用 的 才 知 道 
public ShanzhaicCorp(Product product)t{ 
super (product); 


} 

// 狂 赚钱 

public void makeMoney(){ 
super .makeMoney( ); 
System,out.printlLn(" 我 赚钱 呀 ,, .7")) 





HouseCorp 类 和 ShanZhaiCorp 类 的 区 别 是 在 有 参 构造 的 参数 类 型 
上 ，HouseCorp 类 比较 明确 ， 我 就 是 只 要 House 类 ， 所 以 直接 定义 传递 进 
来 的 必须 是 House 类 ， 一 个 类 尽 可 能 少 地 承担 职责 ， 那 方法 也 一 样 ， 既 
然 HouseCorp 类 已 经 非常 明确 地 只 生产 House 产 品 ， 那 为 什么 不 定义 成 
House 类 型 呢 ? ShanZhaiCorp 就 不 同 了 ， 它 确定 不 了 生产 什么 类 型 。 


好 了 ， 两 大 对 应 的 阵营 都 已 经 产生 了 。 我 们 再 看 Client 程 序 ， 如 代 
码 清单 29-13 所 示 。 


代码 清单 29-13 场景 类 


public class Client { 
public static void main(String[|] args) { 

House house = new House(); 
System,out ， printin(" ------- 房地产 公司 是 这 样 运行 的 ------- 
// 先 找到 房地产 公司 
HouseCorp houseCorp =new HouseCorp(house); 
// 看 我 怎么 挣 钱 
houseCcorp ,makeMoney() ; 
System.out. i A 
// 山 寨 公 司 生产 的 产品 很 多 ， 不 过 我 只 要 指定 产品 就 成 了 
System.out.println("------- 0 ee Wi 
Shanzhaicorp shanzhaiCorp = new Shanzhaicorp(new IPo 
ShanZzhaicorp ,makeMoney( )， 
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生产 出 的 房子 卖 出 去 了 .… 
房地产 公司 赚 大 钱 了 .… 





有 山寨 公司 是 这 样 运行 的 ------ 











生产 出 的 记 od 是 这 个 样子 的 .… 
生产 出 的 记 od 卖 出 去 了 .… 











我 赚钱 呀 .… 











突然 有 一 天 ， 老 板 良 心 发 现 了 ， 不 准备 生产 这 种 “三 无 ”产品 了 ， 那 
我 们 程序 该 怎么 修改 呢 ? 如 果 仍 重 操 旧 业 ， 生 产 衣服 ， 那 该 如 何 处 理 
呢 ? 很 容易 处 理 ， 增 加 一 个 产品 类 ， 然 后 稍稍 修改 一 下 场景 就 可 以 了 ， 
我 们 来 看 衣服 产品 类 ， 如 代码 清单 29-14 所 示 。 














代码 清单 29-14 服装 


public class Clothes extends Product { 
public void beProducted() { 
System.out.println(" 生 产 出 的 衣服 是 这 样 的 ...")， 





} 

public void beSelled() { 
System.out.println(" 生 产 出 的 衣服 卖 出 去 了 ..."); 

} 


然后 再 稍稍 修改 一 下 场景 类 ， 如 代码 清单 29-15 所 示 。 


代码 清单 29-15 场景 类 


public class Client { 
public static void main(String[] args) { 
House house = new House(); 
System,out ， println(" ------- 房地产 公司 是 这 样 运行 的 ------- 
// 先 找到 房地产 公司 





HouseCorp houseCorp =new HouseCorp(house); 

// 看 我 怎么 挣 钱 

houseCorp.makeMoney( ); 

System.out. i 

// 山 寨 公 司 生产 的 产品 很 多 ， 不 过 我 只 要 指定 产品 就 成 了 
System,out,.println("------- 公司 是 这 样 运行 的 ------- 
Shanzhaicorp shanzhaiCorp = new Shanzhaicorp(new Clo 
shanzhaiCorp.makeMoney( ); 
































修改 后 的 运行 结果 如 下 所 示 : 


Ear 房地产 公司 是 这 样 运行 的 ------ 





生产 出 的 房子 是 这 样 的 … 








生产 出 的 房子 卖 出 去 了 .… 





房地产 公司 赚 大 钱 了 .… 


A 山寨 公司 是 这 样 运行 的 ------- 








生产 出 的 衣服 是 这 样 的 … 








生产 出 的 衣服 卖 出 去 了 .… 











我 赚钱 呀 .… 





看 代码 中 的 黑体 部 分 ， 就 修改 了 这 一 条 语句 就 完成 了 生产 产品 的 转 
换 。 那 我 们 深入 思考 一 下 ， 既 然 万 物 都 是 运动 的 ， 我 现在 只 有 房 
司 和 山 罕 公 司 ， 那 以 后 我 会 不 会 增加 一 些 其 他 的 公司 呢 ? 或 者 房地产 公 
司 会 不 会 对 业务 进行 细 化 ， 如 分 为 公寓 房 公司 、 别 墅 公司 ， 以 及 丙 业 房 
公司 等 呢 ? 那 我 告诉 你 ， 会 的 ! 绝对 会 的 ! 但 是 你 发 党 没有 ， 这 种 变化 
对 我 们 上 面 的 类 图 来 说 不 会 做 大 的 修改 ， 充 其 量 只 是 扩展 : 











e 增加 公司 ， 要 么 继承 Corp 类 ， 要 么 继承 HouseCorp 或 


ShanZhaiCorp， 不 用 再 修改 原 有 的 类 了 。 


e 增加 产品 ， 继 承 Product 类 ， 或 者 继承 House 类 ， 你 要 把 房子 分 为 
公寓 房 、 别 墅 、 商 业 用 房 等 。 


你 唯一 要 修改 的 就 是 Client 类 。 类 都 增加 了 ， 高 层 模块 也 需要 修 
改 ， 也 就 是 说 Corp 类 和 Product 类 都 可 以 自由 地 扩展 ， 而 不 会 对 整个 应 用 
产生 太 大 的 变更 ， 这 就 是 桥 染 模式 。 


29.2 桥梁 模式 的 定义 


桥梁 模式 (Bridge Pattern ) 也 叫做 桥接 模式 ， 是 一 个 比较 简单 的 模 
式 ， 其 定义 如 下 : Decouple an abstraction from its implementation so that 
the two can vary independently.( 将 抽象 和 实现 解 厢 ， 使 得 两 者 可 以 独立 
地 变化 。) 





桥梁 模式 的 重点 是 在 “ 解 看 * 上 ， 如 何 让 它们 两 者 解 厢 是 我 们 要 了 解 
的 重点 ， 我 们 先 来 看 桥梁 模式 的 通用 类 ， 如 图 29-4 所 示 。 





Implementor 






+QOperation() 






+OperationImp() 





RefinedAbstraction 






ConcretelImple mentor 
| 
| | 
图 29-4 桥 帝 模式 通用 类 图 





我 们 先 来 看 桥梁 模式 中 的 4 个 角色 。 





抽象 化 角色 


@ Abstraction 








它 的 主要 职责 是 定义 出 该 角色 的 行为 ， 同 时 保存 一 个 对 实现 化 角色 
的 引用 ， 该 角色 一 般 是 抽象 类 。 


实现 化 角色 


® Implementor 





它 是 接口 或 者 抽象 类 ， 定 义 角 色 必 需 的 行为 和 属性 。 





e@ RefinedAbstraction 修正 抽象 化 角色 


它 引用 实现 化 角色 对 抽象 化 角色 进行 修正 。 


具体 实现 化 角色 


e@ ConcreteImplementor 








它 实现 接 口 或 抽象 类 定义 的 方法 和 属性 。 


桥梁 模式 中 的 几 个 名 词 比 较 抛 口 ， 大 家 只 要 记 住 一 句 话 就 成 : 抽象 
角色 引用 实现 角色 ， 或 者 说 抽象 角色 的 部 分 实现 是 由 实现 角色 完成 的 。 
我 们 来 看 其 通用 源码 ， 先 看 实现 化 角色 ， 如 代码 清单 29-16 所 示 。 





代码 清单 29-16 实现 化 角色 








public interface Implementor { 
// 基 本 方法 
public void doSomething(); 
public void doAnything(); 





它 没 有 任何 特殊 的 地 方 ， 就 是 一 个 一 般 的 接口 ， 定 义 要 实现 的 方 
法 。 其 实现 类 如 代码 清单 29-17 所 示 。 


代码 清单 29-17 具体 实现 化 角色 


public class ConcreteImplementor1i implements Implementor{ 
public void doSomething(){ 
// 业 务 逻 辑 人 处 理 























} 

public void doAnything(){ 
// 业 务 逻 辑 处 理 

} 


public class ConcreteImplementor2 implements Implementor{ 
public void doSomething(){ 
// 业 务 逻 辑 处 理 









































了 

public void doAnything(){ 
// 业 务 逻 辑 处 理 

} 


























上 面 定 义 了 两 个 具体 实现 化 角色 一 一 代表 两 个 不 同 的 业务 逻辑 。 我 
们 再 来 看 抽象 化 角色 ， 如 代码 清单 29-18 所 示 。 


代码 清单 29-18 抽象 化 角色 


public abstract class Abstraction { 
// 定 义 对 实现 化 角色 的 引用 
private Implementor imp; 
// 约 束 子 类 必须 实现 该 构造 函数 
public Abstraction(Implementor _imp)t{ 
this.imp = _imp; 


} 

// 自 身 的 行为 和 属性 

public void request(){ 
this.imp.doSsomething(); 


} 
// 获 得 实现 化 角色 
public Implementor getImp()t{ 








er 











return imp; 


各 位 可 能 要 问 ， 为 什么 要 增加 一 个 构造 函数 ? 答案 是 为 了 提醒 子 
类 ， 你 必须 做 这 项 工作 ， 指 定 实现 者 ， 特 别 是 已 经 明确 了 实现 者 ， 则 尽 
量 清晰 明确 地 定义 出 来 。 我 们 来 看 具体 的 抽象 化 角色 ， 如 代码 清单 29- 
19 所 示 。 





代码 清单 29-19 具体 抽象 化 角色 


public class RefinedAbstraction extends Abstraction { 
// 敌 写 构 造 函 数 
public RefinedAbstraction(Implementor _imp)t{ 
super(_imp); 


} 

// 修 正 父 类 的 行为 

Q@Override 

public void request(){ 
3 




















* 业务 处 理 ... 
*/ 


super.request(); 
super .getIimp().doAnything(); 


想 想 看 ， 如 果 我 们 的 实现 化 角色 有 很 多 的 子 接口 ， 然 后 是 一 堆 的 子 
实现 。 如 果 在 构造 函数 中 不 传递 一 个 尽量 明确 的 实现 者 ， 代 码 就 很 不 清 
晰 。 我 们 来 看 场景 类 如 何 模拟 ， 如 代码 清单 29-20 所 示 。 


代码 清单 29-20 场景 类 


public class Client { 
public static void main(String[] args) { 
// 定 义 一 个 实现 化 角色 


Ey 








Implementor imp = new ConcreteImplementor1(); 
// 定 义 一 个 抽象 化 角 
Abstraction abs = new RefinedAbstraction(imp); 
// 执 行 行文 

abs.request(); 


Ey 











桥梁 模式 是 一 个 非常 简单 的 模式 ， 它 只 是 使 用 了 类 间 的 聚合 关系 、 
继承 、 禾 写 等 第 用 功能 ， 但 是 它 却 提供 了 一 个 非常 清晰 、 稳 定 的 染 构 。 


29.3 桥梁 模式 的 应 用 


29.3.1 桥梁 模式 的 优 扣 


e 抽象 和 实现 分 离 


这 也 是 桥梁 模式 的 主要 特点 ， 它 完全 是 为 了 解决 继承 的 缺 丘 而 提出 
的 设计 模式 。 在 该 模式 下 ， 实 现 可 以 不 受 抽象 的 约束 ， 不 用 再 绑 定 在 一 
个 固定 的 抽象 层次 上 。 


e 优秀 的 扩充 能 


看 看 我 们 的 例子 ， 想 增加 实现 ? 没 问 题 ! 想 增 加 抽象 ， 也 没有 问 
题 ! 只 要 对 外 其 露 的 接口 层 人 允许 这 样 的 变化 ， 我 们 已 经 把 变化 的 可 能 性 
减 到 最 小 。 





e 实现 细节 对 客户 透明 


客户 不 用 关心 细节 的 实现 ， 它 已 经 由 抽象 层 通过 聚合 关系 完成 了 封 
装 。 


29.3.2 桥梁 模式 的 使 用 场景 


e 个 布 望 或 不 适用 使 用 继承 的 场景 


例如 继承 层次 过 渡 、 无 法 更 细 化 设计 颗粒 等 场景 ， 需 要 考虑 使 用 桥 


染 模式 。 
e 接口 或 抽象 类 不 稳定 的 场景 


明知 道 接口 不 稳定 还 想 通 过 实现 或 继承 来 实现 业务 需求 ， 那 是 得 不 
偿 失 的 ， 也 是 比较 失败 的 做 法 。 


e 重用 性 要 求 较 高 的 场景 
设计 的 颗粒 撤 越 细 ， 则 被 重用 的 可 能 性 残 越 大 ， 而 采用 继承 则 受 父 


类 的 限制 ， 不 可 能 出 现 太 细 的 颗粒 撒 。 


29.3.3 桥梁 模式 的 注意 事项 





桥梁 模式 是 非常 简单 的 ， 使 用 该 模式 时 主要 考虑 如 何 拆 分 抽象 和 实 
现 ， 并 不 是 一 涉及 继承 就 要 考虑 使 用 该 模式 ， 那 还 要 继承 干什么 呢 ? 桥 
沉 模式 的 意图 还 是 对 变化 的 封装 ， 尽 量 把 可 能 变化 的 因素 封装 到 最 细 、 
最 小 的 逻辑 单元 中 ， 避 免 风 险 扩 散 。 因 此 读者 在 进行 系统 设计 时 ， 发 现 
类 的 继承 有 N 层 时 ， 可 以 考虑 使 用 桥梁 模式 。 


29.4 最 佳 实践 





大 家 对 类 的 继承 有 什么 看 法 吗 ? 继承 的 优点 有 很 多 ， 可 以 把 公共 的 
方法 或 属性 抽取 ， 父 类 封装 共性 ， 子 类 实现 特性 ， 这 是 继承 的 基本 功 
能 。 缺 点 有 没有 ? 有 ! 即 强 侵入 ， 父 类 有 一 个 方法 ， 子 类 也 必须 有 这 个 
方法 。 这 是 不 可 选择 的 ， 会 带 来 扩展 性 的 问题 。 我 举 个 简单 的 例子 来 说 
明 : Father 类 有 一 个 方法 A，Son 继 承 了 这 个 方法 ， 然 后 GrandSon 也 继承 
了 这 个 方法 ， 问 题 是 突然 有 一 天 Son 要 重 写 父 类 的 这 个 方法 ， 他 敢 做 
吗 ? 绝对 不 敢 ! GrandSon 要 用 从 Father 继 承 过 来 的 方法 A， 如 果 你 修改 
了 ， 那 就 要 修改 gon 和 GrandSon 之 间 的 关系 ， 那 这 个 风险 就 太 大 了 ! 











这 里 讲 的 这 个 桥 染 模式 就 是 这 一 问题 的 解决 方法 ， 桥 染 模 式 描述 了 
类 间 弱 关联 关系 ， 还 说 上 面 的 那个 例子 ，Father 类 完全 可 以 把 可 能 会 变 
化 的 方法 放出 去 ，Son 子 类 要 拥有 这 个 方法 很 简单 ， 桥 架 拱 过去， 获得 
这 个 方法 ，GrandSon 也 一 样 ， 即 使 你 Son 子 类 不 想 使 用 这 个 方法 也 没 关 
系 ， 对 GrandSon 不 产生 影响 ， 它 不 是 从 Son 中 继承 来 的 方法 ! 














不 能 次 继承 不 好 ， 它 非常 好 ， 但 是 有 人 缺点， 我 们 可 以 扬长 避 短 ， 对 
于 比较 明确 不 发 生变 化 的 ， 则 通过 继承 来 完成 ， 夺 不 能 确定 是 否 会 发 生 
变化 的 ， 那 残 认为 是 会 发 生变 化 ， 则 通过 桥梁 模式 来 解决 ， 这 才 是 一 个 
完美 的 世界 。 
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第 30 草 ”创建 类 模式 大 PK 


创建 类 模式 包括 工厂 方法 模式 、 建 造 者 模式 、 抽 象 工厂 模式 、 单 例 
模式 和 原型 模式 ， 它 们 都 能 够 提供 对 象 的 创建 和 管理 职责 。 其 中 的 单 例 
模式 和 原型 模式 非常 容易 理解 ， 单 例 模 式 是 要 保持 在 内 存 中 只 有 一 个 对 
象 ， 原 型 模式 是 要 求 通 过 复制 的 方式 产生 一 个 新 的 对 象 ， 这 两 个 不 容易 
混淆 。 剩 下 的 就 是 工厂 方法 模式 、 抽 象 工 三 模式 和 建造 者 模式 了 ， 这 二 
个 之 间 有 较 多 的 相似 性 。 











30.1 工厂 方法 模式 VS 建造 者 模式 








工矿 方法 模式 注重 的 是 整体 对 象 的 创建 方法 ， 而 建造 者 模式 注重 的 
古 部 件 构建 的 过 程 ， 提 在 通过 一 步 一 步 地 精确 构造 创建 出 一 个 复杂 的 对 
象 。 我 们 举 个 简单 例子 来 说 明 两 者 的 差异 ， 如 要 制造 一 个 超人 ， 如 果 使 
用 工厂 方法 模式 ， 直 接 产 生出 来 的 束 是 一 个 力 大 无 穷 、 能 够 飞翔 、 内 裤 
外 罕 的 超人 ;而 如 果 使 用 建造 者 模式 ， 则 需要 组 装 手 、 头 、 脚 、 了 髓 干 等 
部 分 ， 然 后 再 把 内 裤 外 穿 ， 于 是 一 个 超人 就 诞生 了 。 纯 粹 使 用 文字 来 摘 
述 比较 枯燥 ， 我 们 还 是 通过 程序 来 更 加 清晰 地 认识 两 者 的 兰 别 。 





30.1.1 按 工 三 方法 建造 超人 


首先 ， 按 照 工厂 方法 模式 创建 出 一 个 超人 ， 类 图 如 图 30-1 所 示 。 






Client 


SuperManFactory 
| 


) 










+HSuperMan createSuperMan(String type 





<<interface>> 


图 30-1 按 工 厂 方法 建造 超人 


类 图 中 我 们 按照 年 龄 段 把 超人 分 为 两 种 类 型 : 成 年 超人 《如 克拉 
克 、 超 能 先生 ) 和 未 成 年 超人 《如 Dash、Jack) 。 这 是 一 个 非常 正宗 的 
工厂 方法 模式 ， 定 义 一 个 产品 的 接口 ， 然 后 再 定义 两 个 实现 ， 通 过 超人 
制造 工厂 制造 超人 。 想 想 看 我 们 对 超人 最 大 印象 是 什么 ? 当然 是 他 的 超 
能 力 ， 我 们 以 specialTalent 〈 特 殊 天 赋 ) 方法 来 代表 ， 先 看 抽象 产品 
类 ， 如 代码 清单 30-1 所 示 。 





代码 清单 30-1 超人 接口 


public interface ISuperMan { 
// 每 个 超人 都 有 特殊 技能 


public void specialTalent( ); 








产品 的 接口 定义 好 了 ， 我 们 再 来 看 具体 的 产品 。 先 看 成 年 超人 ， 很 
简单 ， 如 代码 清单 30-2 所 示 。 


代码 清单 30-2 成 年 超人 


public class AdultSuperMan implements ISuperMan { 
// 超 能 先生 
public void specialTalent() { 
System.out,printlLn(" 超 人 力 大 无 穷 " ) ; 
} 


未 成 年 超人 的 代码 如 代码 清单 30-3 所 示 。 


代码 清单 30-3 未 成 年 超人 


public class ChildSuperMan implements ISuperMan { 
// 超 能 先生 的 三 个 孩子 
public void specialTalent() { 
System.out.println(" 小 超人 的 能 力 是 刀枪 不 入 、 快 速 运动 " ) ; 
} 





产品 都 具备 ， 那 我 们 编写 一 个 工 三 类， 其 意图 就 是 生产 超人 ， 有 只 体 
古 成 年 超人 还 是 未 成 年 超人 ， 则 由 客户 端 决定 ， 如 代码 清单 30-4 所 示 。 


代码 清单 30-4 超人 制造 工厂 


public class SuperManFactory { 
// 定 义 一 个 生产 超人 的 工厂 
public static ISuperMan createSuperMan(String type)t 
// 根 据 输入 参数 产生 不 同 的 超人 





if(type.equalsIgnoreCase("adult"))t{ 
// 生 产 成 人 超人 
return new AdultSuperMan( ); 
}else if(type.equalsIgnoreCase("child"))t{ 
// 生 产 未 成 年 超人 
return new ChildSuperMan( ); 
}elset 
return null; 
} 


ww 





产品 有 了 ， 工 厂 类 也 有 了 ， 剩 下 的 工作 就 是 开始 生产 超人 。 这 也 非 
常 简 单 ， 如 代码 清单 30-5 所 示 。 


代码 清单 30-5 场景 类 


public class Client { 
// 模 拟 生 产 超人 
public static void main(String[|] args) { 
// 生 产 一 个 成 年 超人 
ISuperMan adultSuperMan = SuperManFactory.createSupe 
// 展 示 一 下 超人 的 技能 
adultSuperMan.specialTalent(); 


建立 了 一 个 超人 生产 工厂 ， 年 复 一 年 地 生产 超人 ， 对 于 具体 生产 出 
的 产品 ， 不 管 是 成 年 超人 还 是 未 成 年 直人， 都 是 一 个 模样 : 深 是 色 紧 身 
衣 、 胸 前 $ 标 记 、 内 裤 外 穿 ， 没 有 特殊 的 地 方 。 但 是 我 们 的 目的 达到 了 
一 一 生产 出 超人 ， 拖 救 全 人 类 ， 这 了 就 是 我 们 的 意图 。 有 具体 怎 么 生产 、 怎 
么 组 装 ， 这 不 是 工矿 方法 模式 要 考 夸 的 ， 也 束 是 说 ， 工 三 模式 关注 的 是 
一 个 产品 整体 ， 生 产 出 的 产品 应 该 具有 相似 的 功能 和 架构 。 











注意 ”通过 工厂 方法 模式 生产 出 对 象 ， 然 后 由 客户 端 进行 对 象 的 
其 他 操作 ， 但 是 并 不 代表 所 有 生产 出 的 对 象 都 必须 具有 相同 的 状态 和 行 





30.1.2 按 建 造 者 模式 建造 超人 











我 们 再 来 看 看 建造 者 模式 是 如 何 生产 超人 的 ,如 图 30-2 所 示 。 









#SuperMan superMan 


+void setBody(String body) 

+void setSpecialTalent(String st) 
+void setSpecialSymbol(String ss) 
+SuperMan getSuperMan() 


-String body 








;sl -Strmg specialTalent 
-String SpecialSymbol 


+getter/setter() 








AdultSuperManBuilder ChildSuperManBuilder 











图 30-2 按 建造 者 模式 生产 超人 


又 是 一 个 典型 的 建造 者 模式 ! 哎 ， 不 对 呀 ! 通用 模式 上 抽象 建造 者 
与 产品 类 没有 关系 呀 ! 是 的 ， 我 们 当然 可 以 加 强 了 ， 我 们 在 抽象 建造 者 
上 使 用 了 模板 方法 模式 ， 每 一 个 建造 者 都 必须 返回 一 个 产品 ， 但 是 产品 
是 如 何 制造 的 ， 则 由 各 个 建造 者 自己 负责 。 我 们 来 看 看 程序 ， 先 看 产品 
类 ， 如 代码 清单 30-6 所 示 。 














代码 清单 30-6 超人 产品 


public class SuperMan { 

// 超 人 的 驱 体 

private String body; 

// 超 人 的 特殊 技能 

private String specialTalent; 

// 超 人 的 标志 

private String specialSymbol; 

public String getBody() { 
return body; 








} 
public void setBody(String body) { 
this.body = body; 


public String getSpecialTalent() { 
return specialTalent; 


public void setSpecialTalent(String specialTalent) { 
this.specialTalent = specialTalent; 


} 
public String getSpecialSymbol() { 
return specialSymbol; 


} 

public void setSpecialSymbol(String specialSymbol) { 
this.specialSymbol = specialSymbol; 

} 








超人 这 个 产品 是 由 三 部 分 组 成 : 躯体 、 特 殊 技 能 、 身 份 标 记 ， 这 就 
类 似 于 电子 产品 ， 首 先生 产 出 一 个 固件 ， 然 后 再 安装 一 个 灵 瑰 (软件 驱 
动 ) ， 最 后 再 打上 产品 标签 。 完 事 了 ! 一 个 崭新 的 产品 就 诞生 了 ! 我 们 
的 超人 也 是 这 样 生产 的 ， 先 生产 一 个 普通 的 躯体 ， 然 后 注入 特殊 技能 ， 
最 后 打上 S 标 签 ， 一 个 超人 生产 完毕 。 我 们 再 来 看 一 下 建造 者 的 抽象 定 
义 ， 如 代码 清单 30-7 所 示 。 














代码 清单 30-7 抽象 建造 者 


public abstract class Builder { 
// 定 义 一 个 超人 的 应 用 
protected final SuperMan SuperMan = new SuperMan( ) ; 








// 构 建 出 超人 的 驱 体 
public void setBody(String body)t{ 
this.superMan.setBody(body); 


} 

// 构 建 出 超人 的 特殊 技能 

public void setSpecialTalent(String st)t{ 
this.superMan.setSpecialTalent(st); 


} 

// 构 建 出 超人 的 特殊 标记 

public void setSpecialSymbol(String ss)t{ 
this.superMan.setSpecialSymbol(ss); 


} 
// 构 建 出 一 个 完整 的 超人 
public abstract SuperMan getSuperMan( ) ， 














一 个 典型 的 模板 方法 模式 ， 超 人 的 各 个 部 件 ( 驱 体 、 灵 瑰 、 标 志 ) 
都 准备 好 了 ， 具 体 怎么 组 装 则 是 由 实现 类 来 决定 。 我 们 先 来 看 成 年 超 
人 ， 如 代码 清单 30-8 所 示 。 


代码 清单 30-8 成 年 超人 建造 者 


public class AdultSuperManBuilder extends Builder { 
@Override 
public SuperMan getSuperMan() { 
super .setBody(" 强 壮 的 躯体 " ) ; 
super .setSpecialTalent ("会 飞行 ")，; 
super ,setSpecialSymbol(" 胸 前 带 S 标 记 ")，; 
return super.superMan; 








么 回 事 ? 在 第 11 章 中 讲解 建造 者 模式 的 时 候 在 产品 中 使 用 了 模板 
方法 模式 ， 在 这 里 怎么 把 模板 方法 模式 迁移 到 建造 者 了 ? 怎么 会 这 样 ? 
你 是 不 是 在 发 出 这 样 的 疑问 ? 别 疑 问 了 ! 设计 模式 只 是 提供 了 一 个 解决 
问题 的 意图 : 复杂 对 象 的 构建 与 它 的 表示 分 离 ， 而 没有 具体 定 出 一 个 设 

















计 模 式 必须 是 这 样 的 实现 ， 必 须 是 这 样 的 代码 ， 灵 活 运 用 模式 才 是 其 根 
本 ， 别 学 死板 了 。 





我 们 继续 看 未 成 年 超人 的 建造 者 ， 如 代码 清单 30-9 所 示 。 


代码 清单 30-9 未 成 年 超人 建造 者 


public class ChildSuperManBuilder extends Builder { 
@Override 
public SuperMan getSuperMan() { 
super .setBody(" 强 壮 的 躯体 " ) ; 
super ,setSpecialTalent(" 刀 枪 不 入 ") ) 
super ,setSpecialSymbol(" 胸 前 带 小 S 标 记 " ) ， 
return Super ,SuperMan ， 





大 家 注意 看 我 们 这 两 个 具体 的 建造 者 ， 它 们 都 关注 了 产品 的 各 个 音 
分 ， 在 某 些 应 用 场景 下 甚至 会 关心 产品 的 构建 顺序 ， 即 使 是 相同 的 部 
件 ， 装 配 顺序 不 同 ， 产 生 的 结果 也 不 同 ， 这 也 正 是 建造 者 模式 的 意图 : 
通过 不 同 的 部 件 、 不 同 装配 产生 不 同 的 复杂 对 象 。 我 们 再 来 看 导演 类 ， 
如 代码 清单 30-10 所 示 。 








代码 清单 30-10 导演 类 


public class Director { 

// 两 个 建造 者 的 应 用 
private static Builder adultBuilder = new AdultSuperManBuil 
// 未 成 年 超人 的 建造 者 
private static Builder childBuilder = new ChildSuperManBuild 
// 建 造 一 个 成 年 、 会 飞行 的 超人 
public static SuperMan getAdultSuperMan( ){ 

return adultBuilder .getSuperMan( ); 


} 
// 建 造 一 个 未 成 年 、 刀 枪 不 入 的 超人 




















public static SuperMan getCchildSuperMan( ){ 
return childBuilder .getSuperMan( ); 
} 





这 很 简单 ， 不 多 说 了 ! 看 看 场景 类 是 如 何 调用 的 ， 如 代码 清单 30- 


11 所 示 。 





代码 清单 30-11 场景 类 


public class Client { 
public static void main(String[] args) { 
// 建 造 一 个 成 年 超人 
SuperMan adultSuperMan = Director.getAdultSuperMan() 
// 展 示 一 下 超人 的 信息 
adultSuperMan.getSpecialTalent(); 





这 个 场景 类 的 写法 与 工厂 方法 模式 是 相同 的 ， 但 是 你 可 以 看 到 ， 在 
建立 超人 的 过 程 中 ， 建 造 者 必须 关注 超人 的 各 个 部 件 ， 而 工 广 方法 模式 
则 只 关注 超人 的 整体 ， 这 就 是 两 者 的 区 别 。 


30.1.3 最 佳 实 践 


工厂 方法 模式 和 建造 者 模式 都 属于 对 象 创建 类 模式 ， 都 用 来 创建 类 
的 对 象 。 但 它们 之 间 的 区 别 还 是 比较 明显 的 。 


e 意图 不 同 


在 工厂 方法 模式 里 ， 我 们 关注 的 是 一 个 产品 整体 ， 如 超人 整体 ， 无 


须 关 心 产 品 的 各 部 分 是 如 何 创建 出 来 的 ， 但 在 建造 者 模式 中 ， 一 个 具体 
产品 的 产生 是 依赖 各 个 部 件 的 产生 以 及 效 配 顺序 ， 它 关注 的 是 “由 零件 

步 一 步 地 组 装 出 产品 对 象 ?。 简 单 地 说 ， 工 厂 模 式 是 一 个 对 象 创建 的 
粗 线条 应 用 ， 建 造 者 模式 则 是 通过 细 线 条 勾勒 出 一 个 复 末 对 象 ， 关 注 的 
是 产品 组 成 部 分 的 创建 过 程 。 








e 产品 的 复杂 度 不 同 


工厂 方法 模式 创建 的 产品 一 般 都 是 单一 性 质 产品 ， 如 成 年 超人 ， 都 
古 一 个 模样 ， 而 建造 者 模式 创建 的 则 是 一 个 复合 产品 ， 它 由 各 个 部 件 复 
合 而 成 ， 部 件 不 同 产品 对 象 当然 不 同 。 这 不 是 说 工厂 方法 模式 创建 的 对 
象 简单 ， 而 是 指 它们 的 粒度 大 小 不 同 。 一 般 来 说 ， 工 广 方法 模式 的 对 象 
粒度 比较 粗 ， 建 造 者 模式 的 产品 对 象 粒度 比较 细 。 











两 者 的 区 别 有 了 ， 那 在 具体 的 应 用 中 ， 我 们 该 如 何 选 择 呢 ? 是 用 工 
三方 法 模式 来 创建 对 象 ， 还 是 用 建造 者 模式 来 创建 对 象 ， 这 完全 取决 于 
我 们 在 做 系统 设计 时 的 意图 ， 如 果 需 要 详细 关注 一 个 产品 部 件 的 生产 、 
安装 步骤 ， 则 选择 建造 者 ， 否 则 选择 工厂 方法 模式 。 





30.2 抽象 工厂 模式 VS 建造 者 模式 





抽象 工厂 模式 实现 对 产品 家 族 的 创建 ， 一 个 产品 家 族 是 这 样 的 一 系 
列 产 品 ， 具 有 不 同 分 类 维度 的 产品 组 合 ， 采 用 抽象 工厂 模式 则 是 不 需要 
关心 构建 过 程 ， 只 关心 什么 产品 由 什么 工厂 生产 即 可 。 而 建造 者 模式 则 
是 要 求 按照 指定 的 蓝图 建造 产品 ， 它 的 主要 目的 是 通过 组 装 零 配件 而 产 
生 一 个 新 产品 ， 两 者 的 区 别 还 是 比较 明显 的 ， 但 是 还 有 读者 对 这 两 个 模 
式 产 生 混淆 ， 我 们 通过 一 个 例子 说 明 两 者 的 差别 。 














现代 化 的 汽车 工厂 能 够 批量 生产 汽车 不 考虑 手工 打造 的 罕 华 
车 ) 。 不 同 的 工矿 生产 不 同 的 汽车 ， 宝 马 工 三 生产 宝 马 牌 子 的 车 ， 奔 驰 
工厂 生产 奔驰 牌子 的 车 。 车 不 仅 具 有 不 同 品牌 ， 还 有 不 同 的 用 途 分 类 ， 
如 商务 车 Van， 运 动 型 车 SUV 和 等， 我 们 按照 两 种 设计 模式 分 别 实现 车 辆 
的 生产 过 程 。 














30.2.1 按 抽 象 工 厂 模 式 生产 车 辆 








按照 抽象 工厂 模式 ， 首 先 需 要 定义 一 个 抽象 的 产品 接口 即 汽车 接 
口 ， 然 后 到 马 和 奔驰 分 别 实 现 该 接口 ， 由 于 它们 只 具有 了 一 个 品牌 属 
性 ， 还 没有 定义 一 个 具体 的 型 号 ， 属 于 对 象 的 抽象 层次 ， 每 个 具体 车 型 
由 其 子 类 实现 ， 如 R 系 列 的 奔驰 车 是 商务 车 ，X 系 列 的 宝马 车 属于 








SUV， 我 们 来 看 类 图 ， 如 图 30-3 所 示 。 





<<interface>> 
ICar 
| 


+String getBand() 
+String getModel() 









AbsBMW 












<<interface>> 
CarFactory 
| 
+Strin +String getBand() 


| 
+ICar createSuv() 
+ICar createVan() 
八 g getBand() I 


ee 


图 30-3 车 辆 生产 的 工厂 类 图 








在 类 图 中 ， 产 品类 很 简单 ， 我 们 从 两 个 维度 看 产品 ， 品牌 和 车 型 ， 
每 个 品牌 下 都 有 两 个 车 型 ， 如 宝马 SUV， 宝 马 商务 车 等 ， 同 时 我 们 又 建 
造 了 两 个 工厂 ， 一 个 专门 生产 宝马 车 的 宝马 工厂 BMWFactory， 一 个 是 
生产 奔驰 车 的 奔驰 车 生产 工厂 BenzFactory。 当 然 ， 汽 车 工厂 也 有 两 个 不 
同 的 维度 ， 可 以 建立 这 样 两 个 工厂 : 一 个 专门 生产 SUV 车 辆 的 生产 工 
三， 生产 宝马 SUV 和 奔驰 SUV， 另 外 一 个 工厂 专门 生成 商务 车 ， 分 别 是 
宝马 商务 车 和 奔驰 商务 车 ， 这 样 设计 在 技术 上 是 完全 可 行 的 ， 但 是 在 业 
务 上 是 不 可 行 的 ， 为 什么 ? 这 是 因为 你 看 到 过 有 一 个 工厂 既 能 生产 奔驰 
SUV 也 能 生产 宝马 SUV 吗 ? 这 是 不 可 能 的 ， 因 为 业务 受 限 ， 除 非 是 国内 
的 山寨 工厂 。 我 们 先 来 看 产品 类 ， 汽 车 接口 如 代码 清单 30-12 所 示 。 




















代码 清单 30-12 汽车 接口 


public interface ICar { 
// 汽 车 的 生产 商 ， 也 就 是 牌子 
public String getBand ( ) ; 
// 汽 车 的 型 号 
public String getModel( ); 





ww 





在 产品 接口 中 我 们 定义 了 和 车辆 有 两 个 可 以 查询 的 属性 : 品牌 和 型 
号 ， 奔 驰 车 和 宝马 车 是 两 个 不 同 品 牌 的 产品 ， 但 不 够 具体 ， 只 是 知道 它 
们 的 品牌 而 已 ， 还 不 能 够 实例 化 ， 因 此 还 是 一 个 抽象 类 ， 如 代码 清单 
30-13 所 示 。 

















代码 清单 30-13 抽象 宝马 车 


public abstract class AbsBMW implements ICar { 
private final static String BMW_BAND = "军马 汽车 "， 
// 宝 马车 
public String getBand() { 
return BMW_BAND; 











} 
// 型 号 由 具体 的 实现 类 实现 
public abstract String getModel(); 














抽象 产品 类 中 实现 了 产品 的 类 型 定义 ， 和 车辆 的 型 写 没 有 实现 ， 两 实 
现 类 分 别 实现 商务 车 和 运动 型 车 ,分别 如 代码 清单 30-14、 代 人 码 清早 30- 





代码 清单 30-14 宝马 商务 车 


public class BMWVan extends AbsBMW { 
private final static String SEVENT_SEARIES = "7 系列 车 型 商务 车 "， 
public String getModel() { 
return SEVENT_SEARIES ， 
} 


代码 清单 30-15 宝马 SUV 


public class BMWSuv extends AbsBMW { 
private final static String X_SEARIES = "X 系 列车 型 SUV"， 
public String getModel() { 
return X_SEARIES ， 
} 








奔驰 车 与 宝 瑟 车 类 似 ， 部 已 经 有 清晰 品牌 定义 ， 但 是 型 号 还 没有 确 
认 ， 也 是 一 个 抽象 的 产品 类 ， 如 代码 清单 30-16 所 示 。 








代码 清单 30-16 抽象 奔驰 车 


public abstract class AbsBenz implements ICar { 
private final static String BENZ_BAND = "奔驰 汽车 "， 
public String getBand() { 
return BENZ_BAND ， 





} 
// 具 体型 号 由 实现 类 完成 
public abstract String getModel(); 

















由 于 分 类 的 标准 是 相同 的 ， 因 此 奔驰 车 也 应 该 有 商务 车 和 运动 车 两 
个 类 型 ， 分 别 如 代码 清单 30-17 和 代码 清单 30-18 所 示 。 


代码 清单 30-17 奔驰 商务 车 


public class BenzVan extends AbsBenz { 
private final static String R_SERIES 
public String getModel() { 
return R_SERIES ， 
} 


} 

代码 清单 30-18 ”奔驰 SUV 

public class BenzSuv extends AbsBenz { 
private final static String G_SERIES = "6 系列 SUV"; 
public String getModel() { 


"R 系 列 商务 车 "; 


return G_SERIES ， 





所 有 的 产品 类 都 已 经 实现 了 ， 剩 下 的 工作 就 是 要 定义 工厂 类 进行 生 
产 ， 由 于 产品 类 型 多 样 ， 也 导致 了 必须 有 多 个 工厂 类 来 生产 不 同 产品 ， 
首先 就 需要 定义 一 个 抽象 工厂 ， 声 明 每 个 工厂 必须 完成 的 职责 ， 如 代码 
清单 30-19 所 示 。 











代码 清单 30-19 抽象 工厂 


public interface CarFactory { 
// 生 产 SUV 
public ICar createSuv(); 
// 生 产 商务 车 
public ICar createVan(); 


抽象 工厂 定义 了 每 个 工厂 必须 生产 两 个 类 型 车 : SUV( 运 动车) 和 
VAN “商务 车 ) ， 人 否则 一 个 工矿 就 不 能 被 实例 化 ， 我 们 来 看 宝马 车 工 
厂 ， 如 代码 清单 30-20 所 示 。 





代码 清单 30-20 宝马 车 工厂 


public class BMWFactory implements CarFactory { 
// 生 产 SUV 
public ICar createSuv() { 
return new BMWSuV( ) ; 


} 

// 生 产 商务 车 

public ICar createVan( ){ 
return new BMWwVan( ); 

a 





很 简单 ， 你 要 我 生产 宝马 商务 车 ， 没 问题 ， 直 接 产 生 一 个 宇 瑟 商务 
车 对 象 ， 返 回 给 调用 者 ， 这 对 调用 者 来 说 根本 不 需要 关心 到 确 是 怎么 生 
产 的 ， 它 只 要 找到 一 个 宝马 工厂 ， 即 可 生产 出 自己 需要 的 产品 ( 汽 
车 ) 。 奔 驰 车 工厂 与 此 类 似 ， 如 代码 清单 30-21 所 示 。 











代码 清单 30-21 奔驰 车 工厂 


public class BenzFactory implements CarFactory { 
// 生 产 SUV 
public ICar createSuv() { 
return new BenzSuv( ) ; 


} 

// 生 产 商务 车 

public ICar createVan( ){ 
return new BenzVan(); 

} 








产品 和 工厂 都 具备 了 ， 剩 下 的 工作 惑 是 建立 一 个 场景 类 模拟 调用 者 
调用 ， 如 代码 清单 30-22 所 示 。 


代码 清单 30-22 场景 类 


public class Client { 
public static void main(String[|] args) { 

// 要 求生 产 一 辆 奔驰 SUV 
System.out.println("=== 要 求生 产 一 辆 奔驰 SUV===" )， 
// 首 先 找 到 生产 奔驰 车 的 工 ) 
System.out.println("A、 找 到 奔驰 车 工厂 ")， 
CarFactory carFactory= new BenzFactory(); 
// 开 始 生产 奔驰 SUV 
System,out.printlLn("B、 开 始 生产 奔驰 SUV" ) ， 
ICar 人 = carFactory.createSuv(); 
// 生 产 完毕 ， 展 示 一 下 车 辆 信息 
System,out.printLn("C、 生 产 出 的 汽车 如 下 : ") ， 
System,out,.println(" 汽 车 品牌 : "+benzSuv.getBand( ) ) ; 
System.out.println(" 汽 车 型 号 : " + benzSuv.getModel()); 


























运行 结果 如 下 所 示 : 





=== 要 求生 产 一 辆 奔驰 SUV=== 





A、 找 到 奔驰 车 工厂 
B、 开 始 生 产 奔 驰 SUV 


C、 生 产 出 的 汽车 如 下 : 





汽车 品牌 : 奔驰 汽车 


汽车 型 号 ，G 系 列 SUV 


对 外 界 调用 者 来 说 ， 只 要 更 换 一 个 具备 相同 结构 的 对 象 ， 即 可 发 生 
非常 大 的 改变 ， 如 我 们 原本 使 用 BenzFactory 生 产 汽 车 ， 但 是 过 了 一 段 时 
间 后 ， 我 们 的 系统 需要 生产 宝马 汽车 ， 这 对 系统 来 说 不 需要 很 大 的 改 
动 ， 只 要 把 工厂 类 使 用 BMWFactory 代 蔡 即 可 ， 立 刻 可 以 生产 出 宝马 
车 ， 注 意 这 里 生产 的 是 一 辆 完整 的 车 ， 对 于 一 个 产品 ， 只 要 给 出 产品 代 
码 〈 车 类 型 ) 即 可 生产 ， 抽 象 工矿 模式 把 一 辆 车 认为 是 一 个 完整 的 、 不 
可 拆 分 的 对 象 。 它 注重 完整 性 ， 一 个 产品 一 旦 找到 一 个 工 广 生产 ， 那 惑 
是 固定 的 型 号 ， 不 会 出 现 一 个 宝马 工厂 生产 奔驰 车 的 情况 。 那 现在 的 问 
题 是 我 们 就 想 要 一 辆 混合 的 车 型 ， 如 奔驰 的 引擎 ， 至 马 的 车 轮 ， 那 该 怎 
么 处 理 呢 ? 使 用 我 们 的 建造 者 模式 ! 








30.2.2 按 建 造 者 模式 生产 车 辆 





按照 建造 者 模式 设计 一 个 生产 车 辆 需要 把 车 辆 进行 拆 分 ， 拆 分 成 引 
擎 和 车 轮 两 部 分 ， 然 后 由 建造 者 进行 建造 ， 想 要 什么 车 ， 你 只 要 有 设计 
图 纸 就 成 ， 马 上 可 以 制造 一 辆 车 出 来 。 它 注重 的 是 对 零件 的 装配 、 组 
合 、 封 装 ， 它 从 一 个 细微 构件 装配 角度 看 待 一 个 对 象 。 我 们 来 看 生产 车 
辆 的 类 图 ， 如 图 30-4 所 示 。 





注意 看 我 们 类 图 中 的 蓝图 类 Blueprint， 它 负责 对 产品 建造 过 程 定 
义 。 既 然 要 生产 产品 ， 那 必然 要 对 产品 进行 一 个 描述 ， 在 类 图 中 我 们 定 
义 了 一 个 接口 来 描述 汽车 ， 如 代码 清单 30-23 所 示 。 


代码 清单 30-23 车 辆 产品 描述 


public interface ICar { 
// 汽 车 车 轮 
public String getwheel() ; 
// 汽 车 引擎 
public String getEngine(); 


Director 


+ICar createBenzSuv() 

+ICar benzBuilder() 

+ICar create BMWVan() 
| +ICar createComplexCar() 














CarBuilder 


| -=== 三 === = 三 三 三 = 全 下 
pep LS 

汽车 建造 者 +void receiveBlueprint(Blueprint _ bp) 
tString buildWheell() 

t+String buildEnginel) 




















BenzBuilder 


图 30-4 建造 者 模式 建造 车 辆 


奔驰 车 建造 者 





-String wheel 
-String engine 


+getter/setter() 


蓝图 





Blueprint 






IN 







<<interface>> 
ICar 


= 
+String getWheel() 
+String getEngine()() 


我 们 定义 一 辆 车 必须 有 车 轮 和 引擎 ， 具 体 的 产品 如 代码 清单 30-24 


所 示 。 


代码 清单 30-24 具体 车 辆 


public class Car implements ICar { 

// 汽 车 引擎 

private String engine 

// 汽 车 车 轮 

private String wheel; 

// 一 次 性 传递 汽车 需要 的 信息 

public Car(String _engine,String _wheel)t{ 
this.engine = _engine; 
this.wheel = _wheel; 








} 

public String getEngine() { 
return engine,; 

} 


public String getwheel() { 
return wheel; 


} 
public String toString(){ 

return "车 的 轮子 是 : " + wheel + "\n 车 的 引擎 是 : " + engin 
} 


一 个 简单 的 JavaBean 定 义 产 品 的 属性 ， 明 确 对 产品 的 描述 。 我 们 继 
续 来 思考 ， 因 为 我 们 的 产品 是 比较 抽象 的 ， 它 没有 指定 引擎 的 型 号 ， 也 
没有 指定 车 轮 的 牌子 ， 那 么 这 样 的 组 合 方式 有 很 多 ， 完 全 要 靠 建造 者 来 
建造 ， 建 造 者 说 要 生产 一 辆 奔驰 SUV 那 就 得 用 奔驰 的 引擎 和 奔驰 的 车 
轮 ， 该 建造 者 对 于 一 个 具体 的 产品 来 说 是 绝对 的 权威 ， 我 们 来 描述 一 下 
建造 者 ， 如 代码 清单 30-25 所 示 。 




















代码 清单 30-25 抽象 建造 者 


public abstract class CarBuilder { 
// 待 建造 的 汽车 
private ICar Car 
// 设 计 蓝 图 
private Blueprint bp; 
public Car buildCar()t{ 
// 按 照 顺序 生产 一 辆 车 
return new Car(buildEngine(),buildwheel( )); 


} 

// 接 收 一 份 设计 蓝图 

public void receiveBlueprint(Blueprint _bp)t{ 
this.bp = _bp; 


} 

// 碍 看 蓝图 ， 只 有 真正 的 建造 者 才 可 以 查看 蓝图 

protected Blueprint getBlueprint()t{ 
return bp; 



































} 

// 建 造 车 轮 

protected abstract String buildwheel(); 
// 建 造 引 擎 

protected abstract String buildEngine(); 





看 到 Blueprint 类 了 ， 它 中 文 的 意思 是 “蓝图 *"， 你 要 建造 一 辆 车 必须 
有 一 个 设计 样稿 或 者 蓝图 吧 ， 和 否则 怎么 生产 ? 怎么 装配 ? 该 类 就 是 一 个 
可 参考 的 生产 样本 ， 如 代码 清单 30-26 所 示 。 


代码 清单 30-26 生产 蓝图 


public class Blueprint { 
// 车 轮 的 要 求 
private String wheel; 
// 引 苟 的 要 求 
private String engine; 
public String getwheel() { 
return wheel; 





} 
public void setwheel(String wheel) { 
this.wheel = wheel; 


} 
public String getEngine() { 
return engine 


public void setEngine(String engine) { 
this.engine = engine; 
} 


这 和 一 个 具体 的 产品 Car 类 是 一 样 的 ? 错 ， 不 一 样 ! 它 是 一 个 蓝 
图 ， 是 一 个 可 以 参考 的 模板 ， 有 一 个 蓝图 可 以 设计 出 非常 多 的 产品 ， 如 
有 一 个 R 系 统 的 奔驰 商务 车 设计 蓝图 ， 我 们 就 可 以 生产 出 一 系列 的 奔驰 
车 。 它 指导 我 们 的 产品 生产 ， 而 不 是 一 个 具体 的 产品 。 我 们 来 看 宝马 车 
建造 车 间 ， 如 代码 清单 30-27 所 示 。 


代码 清单 30-27 宝马 车 建造 车 间 


public class BMWBuilder extends CarBuilder { 
public String buildEngine() { 


return Super.getBlueprint().getEngine()， 


} 
public String buildwheel() { 

return super.getBlueprint().getwheel( ); 
} 


这 是 非常 简单 的 类 。 只 要 获得 一 个 蓝图 ， 然 后 按照 蓝图 制造 引擎 和 
车 轮 即 可 ， 剩 下 的 事情 就 交 给 抽象 的 建造 者 进行 装配 。 奔 驰 车 间 与 此 类 
似 ， 如 代码 清单 30-28 所 示 。 

















代码 清单 30-28 奔驰 车 建造 车 间 


public class BenzBuilder extends CarBuilder { 
public String buildEngine() { 
return super.getBlueprint().getEngine( ); 


} 
public String buildwheel() { 

return super.getBlueprint().getwheel( ); 
} 


两 个 建造 车 间 都 已 经 完成 ， 那 现在 的 问题 就 变 成 了 怎么 让 车 间 运 
作 ， 谁 来 编写 蓝图 ? 谁 来 协调 生产 车 间 ? 谁 来 对 外 提供 最 终 产品 ?于 是 
导演 类 出 场 了 ， 它 不 仅仅 有 每 个 车 间 需 要 的 设计 蓝图 ， 还 具有 指导 不 同 
车 则 装配 顺序 的 职员 ， 如 代码 清单 30-29 所 示 。 











代码 清单 30-29 导演 类 


public class Director { 
// 声 明 对 建造 者 的 引用 
private CarBuilder benzBuilder = new BenzBuilder(); 
private CarBuilder bmwBuilder = new BMWBuilder(); 
// 生 产 奔驰 SUV 
public ICar createBenzSuv( ){ 
// 制 造 出 汽车 











return createCcar(benzBuilder， "benz 的 引擎 "， "benz 的 轮 月 


} 
// 生 产 出 一 辆 宝马 商务 车 
public ICar createBMWVan( ){ 
return createCcar(benzBuilder，"BMW 的 引擎 "，"BMW 的 轮胎 " 


} 
// 生 产 出 一 个 混合 车 型 
public ICar createComplexCar()t{ 
return createCcar(bmwBuilder，"BMW 的 引擎 "，"benz 的 轮胎 " 


} 

// 生 产 车 辆 

private ICar createCar(CarBuilder _carBuilder,String engine, 
// 导 演 怀 揣 赣 图 
Blueprint bp = new Blueprint(); 
bp.setEngine(engine); 
bp.setwheel(wheel ); 
System,out.println(" 获 得 生产 蓝图 " ) ， 
_CarBuilder.receiveBlueprint(bp); 
return _carBuilder.buildCar(); 














这 里 有 一 个 私有 方法 createCar， 其 作用 是 减少 导演 类 中 的 方法 对 蓝 





图 的 依赖 ， 全 部 由 该 方法 来 完成 。 我 们 编写 一 个 场景 类 ， 如 代码 清单 
30-30 所 示 。 


代码 清单 30-30 场景 类 


public class Client { 


public static void main(String[|] args) { 
// 定 义 出 导演 类 
Director director =new Director(); 
// 给 我 一 辆 奔驰 车 SUV 
System,.out,.printlLn("=== 制 造 一 辆 奔驰 SUV===" ) ， 
ICar benzSuv = director.createBenzSuv(); 
System.out .println(benzSuv ) ; 
// 给 我 一 辆 宝马 商务 车 
System.out,printJIn("NXn=== 制 造 一 辆 宝马 商务 车 ===" ) ; 
ICar bmwvan = director,createBMwWVan( ) ; 
System.out .println(bmwVvan ) ， 
// 给 我 一 辆 混合 车 型 
System,out.printlLln("NXn=== 制 造 一 辆 混合 车 ===") ) 


























ICar complexCar = director.createComplexCar( ); 
System.out.println(complexCar); 


场景 类 只 要 找到 导演 类 (也 就 是 车 间 主 任 了 )〉 说 给 我 制造 一 辆 这 样 
的 宝马 车 ， 车 间 主 任 咏 上 通晓 你 的 意图 ， 设 计 了 一 个 获 图 ， 然 后 命令 建 
造 车 间 拼 命 加 班 加 点 建造， 最 终 返 回 给 你 一 件 最 新 出 品 的 产品 ， 运 行 结 
果 如 下 所 示 : 





=== 制 造 一 辆 奔驰 SUV=== 








车 的 轮子 是 : benz 的 轮胎 





车 的 引擎 是 : benz 的 引擎 





=== 制 造 一 辆 至 马 商务 车 === 











车 的 轮子 是 ，BMW 的 轮胎 





车 的 引擎 是 ，BMW 的 引擎 

















=== 制 造 一 辆 混合 车 === 





获得 生产 蓝图 





车 的 轮子 是 : benz 的 轮胎 





车 的 引擎 是 ，BMW 的 引擎 





注意 最 后 一 个 运行 结果 片段 ， 我 们 可 以 立刻 生产 出 一 辆 混合 车 型 ， 
只 要 有 设计 蓝图 ， 这 非常 容易 实现 。 反 观 我 们 的 抽象 工厂 模式 ， 它 是 不 





可 能 实现 该 功能 的 ， 因 为 它 更 关注 的 是 整体 ， 而 不 关注 到 底 用 的 是 奔驰 
引擎 还 是 宝 瑟 引擎 ， 而 我 们 的 建造 者 模式 却 可 以 很 容易 地 实现 该 设计 ， 
市 场 信息 变更 了 ， 我 们 就 可 以 立刻 跟 进 ， 生 产 出 客户 需要 的 产品 。 





30.2.3 最 佳 实 践 


注意 看 上 面 的 描述 ， 我 们 在 抽象 工厂 模式 中 使 用 “工厂 ”来 描述 构建 
者 ， 而 在 建造 者 模式 中 使 用 “车 间 ” 来 描述 构建 者 ， 其 实 我 们 已 经 在 说 它 
们 两 者 的 区 别 了 ， 抽 象 工厂 模式 就 好 比 是 一 个 一 个 的 工厂 ， 宝 蕊 车 工厂 
生产 宝马 SUV 和 宝马 YAN， 奔驰 车 工厂 生产 奔驰 车 SUV 和 奔驰 VAN,， 
它 是 从 一 个 更 高 层次 去 看 对 象 的 构建 ， 具 体 到 工厂 内 部 还 有 很 多 的 车 
间 ， 如 制造 引擎 的 车 间 、 装 配 引擎 的 车 间 等 ， 但 这 些 都 是 隐藏 在 工厂 内 
部 的 细节 ， 对 外 不 公布 。 也 就 是 对 领导 者 来 说 ， 他 只 要 关心 一 个 工厂 到 
底 是 生产 什么 产品 的 ， 不 用 关心 具体 怎么 生产 。 而 建造 者 模式 就 不 同 
了 ， 它 是 由 车 间 组 成 ， 不 同 的 车 间 完 成 不 同 的 创建 和 装配 任务 ， 一 个 完 
整 的 汽车 生产 过 程 需要 引擎 制造 车 间 、 引 擎 装配 车 间 的 配合 才能 完成 ， 
它们 配合 的 基础 就 是 设计 蓝图 ， 而 这 个 蓝图 是 掌握 在 车 间 主 任 〈 导 演 
类 ) 手中 ， 它 给 建造 车 间 什 么 蓝图 就 能 生产 什么 产品 ， 建 造 者 模式 更 关 
心 建造 过 程 。 虽 然 从 外 界 看 来 一 个 车 间 还 是 生产 车 辆 ， 但 是 这 个 车 间 的 
转型 是 非常 快 的 ， 只 要 重新 设计 一 个 蓝图 ， 即 可 产生 不 同 的 产品 ， 这 有 
赖 于 建造 者 模式 的 功劳 。 






































相对 来 说 ， 抽 象 工 厂 模 式 比 建造 者 模式 的 尺度 要 大 ， 它 关注 产品 整 
体 ， 而 建造 者 模式 关注 构建 过 程 ， 因 此 建造 者 模式 可 以 很 容易 地 构建 出 
一 个 细 新 的 产品 ， 只 要 导演 类 能 够 提供 具体 的 工艺 流程 。 也 正 因为 如 
此 ， 两 者 的 应 用 场景 截然 不 同 ， 如 采 和 希望 屏 散 对 象 的 创建 过 程 ， 只 提供 
一 个 封闭 民 好 的 对 象 ， 则 可 以 选择 抽象 工厂 方法 模式 。 而 建造 者 模式 可 
以 用 在 构件 的 装配 方面 ， 如 通过 装配 不 同 的 组 件 或 者 相同 组 件 的 不 同 顺 
序 ， 可 以 产生 出 一 个 新 的 对 象 ， 它 可 以 产生 一 个 非常 灵活 的 架构 ， 方 便 
地 扩展 和 维护 系统 。 





第 31 革 ”结构 类 模式 大 PK 


结构 类 模式 包括 适 配 费 模式 、 桥 染 模 式 、 组 合 模 式 、 沪 饰 模式 、 门 
面 模 式 、 至 元 模式 和 代理 模式 。 为 什么 叫 结构 类 模式 呢 ? 因 为 它们 都 是 
通过 组 合 类 或 对 象 产 生 更 大 结构 以 适应 更 高 层次 的 逻辑 需求 。 我 们 来 分 
析 以 下 几 个 模式 的 相似 点 和 不 同 点 。 





31.1 代理 模式 VS 装饰 模式 


对 于 两 个 模式 ， 首 先 要 说 的 是 ， 装 饰 模式 束 是 代理 模式 的 一 个 特殊 
应 用 ， 两 者 的 共同 点 是 都 具有 相同 的 接口 ， 不 同 点 则 是 代理 模式 着 重 对 
代理 过 程 的 控制 ， 而 装饰 模式 则 是 对 类 的 功能 进行 加 强 或 减弱 ， 它 着 重 
类 的 功能 变化 ， 我 们 举例 来 说 明和 它们 的 区 别 。 





31.1.1 代理 模式 








一 个 著名 的 短跑 运动 员 有 自己 的 代理 人 。 如 果 你 很 仰慕 他 ， 你 找 运 
动员 说 “你 跑 个 我 看 看 ”"， 运 动员 肯定 不 搭理 你 ， 不 过 你 找到 他 的 代理 人 
就 不 一 样 了 ， 你 可 能 和 代理 人 比较 熟 ， 可 以 称 兄 道 弟 ， 这 个 忙 代理 人 还 
是 可 以 帮 的 ， 于 是 代理 人 同意 让 你 欣赏 运动 员 的 练习 赛 ， 这 对 你 来 说 已 
经 是 莫大 的 亦 泡 了。 我 们 来 看 类 图 ， 如 图 31-1 所 示 。 
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+RunnerAgent(IRunner runner) 





图 31-1 运动 员 跑 步 


这 是 一 个 套用 代理 模式 的 简单 应 用 ， 非 党 简单 ! 一 个 对 象 ， 然 后 再 
是 自己 的 代理 。 我 们 先 来 看 一 下 代码 ， 先 看 抽象 主题 类 ， 如 代码 清单 
31-1 所 示 。 


代码 清单 31-1 抽象 运动 员 


public interface IRunner { 
// 运 动员 的 主要 工作 就 是 跑步 
public void run(); 











一 个 具体 的 短跑 运动 员 跑 步 是 很 浦 酒 的 ， 如 代码 清单 31-2 所 示 。 


代码 清单 31-2 运动 员 跑步 


public class Runner implements IRunner { 
public void run() { 
System.out.println(" 运 动员 跑步 : 动作 很 潇洒 " ) ; 
} 


看 看 现在 的 明星 运动 员 ， 一般 都 有 自己 的 代理 人 ， 要 么 是 专职 的 ， 
要 么 就 是 目 己 的 教练 兼职 ， 那 我 们 来 看 看 代理 人 的 职 贡 ， 如 代码 清单 


31-3 所 示 O 


代码 清单 31-3 代理 人 


public class RunnerAgent implements IRunner { 
private IRunner runner ; 
public RunnerAgent(IRunner _runner)t 
this.runner = _runner,; 


} 
// 代 理 人 是 不 会 跑 的 
public void run() { 
Random rand = new Random( ); 
if(rand.nextBoolean())t 
System.out,.printJln(" 代 理 人 同意 安排 运动 员 跑步 " ) ， 
runner .run(); 
}elsef 



























































System.out.println(" 代 理 人 心情 不 好 ， 不 安排 运动 员 E 





我 们 只 是 定义 了 一 个 代理 人 ， 并 没有 明确 定义 是 哪 一 个 运动 员 的 代 
理 ， 需 要 在 运行 时 指定 被 代理 者 ， 而 且 我 们 还 在 代理 人 的 run 方 法 中 做 
了 判断 ， 想 让 被 代理 人 跑步 束 跑 步 ， 不 乐意 就 拒绝 ， 对 于 主题 类 的 行为 
是 否 可 以 发 生 ， 代 理 类 有 绝对 的 控制 权 。 我 们 编写 一 个 场景 类 来 模拟 这 





种 情况 ， 如 代码 清单 31-4 所 示 。 


代码 清单 31-4 场景 类 


public class Client { 
public static void main(String[] args) { 

// 定 义 一 个 短跑 运动 员 
IRunner liu = new Runner(); 
// 定 义 1iu 的 代理 人 
IRunner agent = new RunnerAgent(1iu); 
// 要 求 运 动员 跑步 
System.out .printlin("==== 客 人 找到 运动 员 的 代理 要 求 其 去 跑步 =: 
agent .run(); 









































由 于 我 们 使 用 了 随机 数 产 生 模 拟 结 果 ， 因 此 运行 结果 有 两 种 可 能 情 
一 种 情况 如 下 所 示 : 














==== 客 人 找到 运动 员 的 代理 要 求 其 去 跑步 === 


























代理 人 同意 安排 运动 员 跑 步 





运动 员 跑 步 : 动作 很 潇洒 





运行 结果 的 第 二 种 情况 如 下 所 示 : 

















==== 客 人 找到 运动 员 的 代理 要 求 其 去 跑步 === 























代理 人 心情 不 好 ， 不 安排 运动 员 跑 步 











不 管 是 哪 种 情况 ， 我 们 都 证 实 了 代理 的 一 个 功能 : 在 不 改变 接口 的 
前 提 下 ， 对 过 程 进行 控制 。 在 我 们 例子 中 ， 运 动员 要 不 要 跑步 是 由 代理 
人 决定 的 ， 代 理 人 说 跑步 就 跑步 ， 说 不 跑 束 不 跑 ， 它 有 绝对 判断 权 。 


31.1.2 装饰 模式 





如 果 使 用 装饰 模式 ， 我 们 该 怎么 实现 这 个 过 程 呢 ? 装饰 模式 是 对 类 
功能 的 加 强 ， 怎 么 加 强 呢 ? 增强 跑步 速度 ! 在 屁股 后 面 安 装 一 个 喷气 动 
力 闭 置 ， 类 似 火 稍 的 喷气 装置 ， 那 速度 变 得 很 快 ，《 蜘 蛛 侠 》 中 的 那个 
反面 角色 不 就 是 这 样 的 吗 ? 好 ， 我 们 来 看 类 图 ， 如 图 31-2 所 示 。 





<<mterface>> 
Client IRunner 


+Vvold run() 
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RunnerWithjJet 


Runner 


-IRunner runner() 
+RunnerWithJet(IRunner runner) 





图 31-2 增强 运动 员 的 功能 


很 惊讶 ?这 个 代理 模式 完全 一 样 的 类 图 ?是 的 ， 完 全 一 样 ! 不 过 其 
实现 的 意图 却 不 同 ， 我 们 先 来 看 代码 ，IRunner 和 Runner 与 代理 模式 相 
同 ， 详 见 代 码 清 单 31-1 和 代码 清单 31-2 所 示 ， 在 此 不 再 歼 述 。 我 们 来 看 


装饰 类 RunnerWithJet， 如 代码 清单 31-5 所 示 。 


代码 清单 31-5 装饰 类 


public class RunnerwithJet implements IRunner { 
private IRunner runner; 
public RunnerwithJet(IRunner _runner)t{ 
this.runner = _runner; 


public void run() { 
System.out .println(" 加 快运 动员 的 速度 : 为 运动 员 增 加 喷气 装置 ， 
runner.run(); 








这 和 代理 模式 中 的 代理 类 也 是 非常 相似 的 ， 只 是 装饰 类 对 类 的 行为 
没有 决定 权 ， 只 有 增强 作用 ， 也 就 是 说 它 不 决定 被 代理 的 方法 是 售 执 
行 ， 它 只 是 再 次 增加 被 代理 的 功能 。 我 们 来 看 场景 类 ， 如 代码 清单 31-6 
所 示 。 


代码 清单 31-6 场景 类 


public class Client { 

public static void main(String[|] args) { 
// 定 义 运动 员 
IRunner liu = new Runner(); 
// 对 其 功能 加 强 
liu = new RunnerwithJet(1iu); 
// 看 看 它 的 跑步 情况 如 何 
System.out.println("=== 增 强 后 的 运动 员 的 功能 ===" )， 
Jiu.run( ); 

















-一 


运行 结果 如 下 所 示 : 


=== 增 强 后 的 运动 员 的 功能 === 














加 快运 动员 的 速度 : 为 运动 员 增 加 喷气 装置 


运动 员 跑 步 : 动作 很 潇洒 





注意 思考 一 下 我 们 的 程序 ， 我 们 通过 增加 了 一 个 装饰 类 ， 就 完成 了 
对 原 有 类 的 功能 增加 ， 由 一 个 普通 的 短跑 运动 员 变 成 了 带 有 喷气 装置 的 
超人 运动 员 ， 其 速度 岂 是 普通 人 能 相 比 的 ? ! 





31.1.3 最 佳 实 践 


通过 例子 ， 我 们 可 以 看 出 代理 模式 和 沪 饰 模式 有 非常 相似 的 地 方 ， 
甚至 代码 实现 都 非常 相似 ， 特 别 是 装饰 模式 中 省 略 抽象 装饰 角色 后 ， 两 
者 代码 基本 上 相同 ， 但 是 还 是 有 细微 的 差别 。 








代理 模式 是 把 当前 的 行为 或 功能 委托 给 其 他 对 象 执行 ， 代 理 类 负责 
接口 限定 : 是 否 可 以 调用 真实 角色 ， 以 及 是 否 对 发 送 到 真实 角色 的 消息 
进行 变形 处 理 ， 它 不 对 被 主题 角色 (也 就 是 被 代理 类 ) 的 功能 做 任何 处 
理 ， 保 证 原 汁 原味 的 调用 。 代 理 模 式 使 用 到 极致 开发 就 是 AOP， 这 是 各 
位 采用 Spring 架构 开发 必然 要 使 用 到 的 技术 ， 它 就 是 使 用 了 代理 和 反射 
的 技术 。 





装饰 模式 是 在 要 保证 接口 不 变 的 情况 下 加 强 类 的 功能 ， 它 保证 的 是 
被 修饰 的 对 象 功能 比 原 始 对 象 丰富 〈 当 然 ， 也 可 以 减弱 ) ， 但 不 做 准 入 
条 件 判 断 和 准 入 参数 过 小 ， 如 是 否 可 以 执行 类 的 功能 ， 过 滤 输 入 参数 是 


个 合 规 等 ， 这 不 是 闭 饰 模式 关心 的 。 


代理 模式 在 Java 的 开发 中 俯 拾 缘 是 ， 是 大 家 非常 见 悉 的 模式 ， 应 用 
非常 广泛 ， 而 装饰 模式 是 一 个 比较 拘谨 的 模式 ， 在 实际 应 用 中 接触 比较 
少 ， 但 是 也 有 不 少 框架 项 目 使 用 了 装饰 模式 ， 例 如 在 JDK 的 java.io.* 包 
中 就 大 量 使 用 装饰 模式 ， 类 似 如 下 的 代码 : 


OutputStream out = new DataOutputStream (new FileOutputStream ("te 


这 是 装饰 模式 的 一 个 典型 应 用 ， 使 用 DataOutputStream 封 装 了 一 个 
FileOutputStream， 以 方便 进行 输出 流 处 理 。 


31.2 装饰 模式 VS 适配器 模式 


装饰 模式 和 适配器 模式 在 通用 类 图 上 没有 太 多 的 相似 点 ， 差 别 比 较 
大 ， 但 是 它们 的 功能 有 相似 的 地 方 : 都 是 包 厂 作用 ， 都 是 通过 委托 方式 
实现 其 功能 。 不 同 点 是 : 装饰 模式 包装 的 是 目 己 的 郊 弟 类 ， 隶 属于 同一 
个 家 族 《〈 相 同 接口 或 父 类 ) ， 适 配 右 模式 则 修饰 非 血缘 关系 类 ， 把 一 个 
非 本 家 族 的 对 象 伪 闭 成 本 家 族 的 对 象 ， 注 意 是 伪装 ， 因 此 它 的 本 质 还 是 
非 相 同 接口 的 对 象 。 











大 家 都 应 该 听 过 丑小鸭 的 故事 吧 ， 我 们 今天 就 用 这 两 种 模式 分 别 讲 
述 丑 小 鸭 的 故事 。 话 说 鸡 妈 妈 有 5 个 孩子 ， 其 中 4 个 孩子 都 是 黄白 相间 的 
颜色 ， 而 最 小 的 那 只 也 就 是 叫做 丑小鸭 的 那 上 只 ， 是 纯 日 色 的 ， 与 兄弟 姐 
妹 不 相同 ， 在 遭受 了 诸多 的 别 讽 和 讨 笑 后 ， 最 终 丑 小 鸭 变 成 了 一 只 美丽 
的 天 鹅 。 那 我 们 如 何 用 两 种 不 同 模式 来 描述 这 一 故事 呢 ? 








31.2.1 用 装饰 模式 描述 丑小鸭 


用 奢 饰 模式 来 描述 丑小鸭 ， 首 先 吏 要 肯定 丑小鸭 是 一 只 天 禾 ， 只 是 
因为 她 小 或 者 是 鸭 妈 妈 的 无 知 才 没有 被 认 出 是 天 禾 ， 经 过 一 段 时 间 后 ， 
它 逐 步 变 成 一 个 深 宫 、 上 自信 、 优 美的 白天 鹅 。 根 据 分 析 我 们 可 以 这 样 设 
计 ， 先 设计 一 个 丑小鸭 ， 然 后 根据 时 间 先 后 来 进行 不 同 的 美化 处 理 ， 怎 














么 美化 昵 ? 先 长 出 漂亮 的 羽毛 ， 然 后 逐步 展现 出 异 于 鸭子 的 不 同行 为 ， 
如 飞行 ， 最 终 在 具备 了 所 有 的 行为 后 ， 它 束 成 为 一 只 纯粹 的 白天 鹅 了 ， 
我 们 来 看 类 图 ， 如 图 31-3 所 示 。 














+Decorator(Swan swan) 
+void fly() 

+void cry() 

+void desAppaearance() 
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+BeautifyAppearance(Swan swan) 
t+void desAppaearance() 


图 31-3 装饰 模式 实现 丑小鸭 














类 图 比较 简单 ， 非 第 标 准 的 装饰 模式 。 我 们 按照 故事 的 情节 友 展 一 
步 一 步 地 实现 程序 。 初 期 的 时 候 ， 丑 小 鸭 表 现 得 很 另类 ， 叫 声 不 同 ， 外 
形 不 同 ， 致 使 周围 的 亲 威 、 朋 友 都 对 她 鄙视 ， 那 我 们 来 建立 这 个 过 程 ， 
由 于 恬 小 鸭 的 本 质 就 是 一 个 天 鹅 ， 我 们 就 先生 成 一 个 天 鹅 的 接口 ， 如 代 





码 清 单 31-7 所 示 。 


代码 清单 31-7 天 笋 接 口 


public interface Swan { 
// 天 鹅 会 飞 
public void fly(); 
// 天 笋 会 叫 
public void cry(); 
// 天 和 臣 都 有 漂亮 的 外 表 


public void desAppaearance( ); 





我 们 定义 了 天 鹅 的 行为 ， 都 会 飞行 、 会 叫 ， 并 且 可 以 描述 她 们 漂亮 
的 外 表 。 丑 小 鸭 是 一 只 白天 鹅 ， 是 "is-a" 的 关系 ， 也 就 是 需要 实现 这 
接口 了 ， 其 实现 如 代码 清单 31-8 所 示 。 








代码 清单 31-8 丑小鸭 


public class UglyDuckling implements Swan { 
// 丑 小 鸭 的 叫 声 
public void cry() { 
System.out.println(" 叫 声 是 克 噜 一 克 噜 一 克 噜 ")， 








} 

// 丑 小 鸭 的 外 形 

public void desAppaearance() { 
System,out,printlLn(" 外 形 是 脏 今 今 的 白色 ， 毛 昔 昔 的 大 脑袋 " ) ; 

















} 
// 了 丑小鸭 还 比较 小 ， 不 能 
public void fly() { 
System.out .println(" 不 能 飞行 ");， 
. 





丑小鸭 具备 了 天 殷 的 所 有 行为 和 属性 ， 因 为 她 本 来 就 是 一 只 白天 
鹅 ， 只 是 因为 她 太 小 了 还 不 能 飞行 ， 也 不 能 照顾 自己 ， 所 以 丑 丑 的 ， 在 





经 过 长 时 间 的 流浪 生活 后 ， 丑 小 鸭 长 大 了 。 终 于 有 一 天 ， 她 发 现 自 己 葛 
然 变 成 了 一 只 美丽 的 白天 和 忽 ， 有 大 深 肝 、 洁 日 的 羽毛 ， 而 且 还 可 以 飞 
行 ， 这 完全 是 一 种 升华 行为 。 我 们 来 看 看 她 的 行为 《飞行 ) 和 属性 〈 外 
形 ) 是 如 何 加 强 的 ， 先 看 抽象 的 装饰 类 ， 如 代码 清单 31-9 所 示 。 








代码 清单 31-9 抽象 装饰 类 


public class Decorator implements Swan { 
private Swan swan; 
// 修 饰 的 是 谁 
public Decorator(Swan _swan)t{ 
this. swan =_swan; 





} 
public void cry() { 
swan.cry(); 


public void desAppaearance() { 
swan.desAppaearance( ); 


} 

public void fly() { 
swan.fly(); 

} 


这 是 一 个 非常 简单 的 代理 模式 。 我 们 再 来 看 丑小鸭 是 如 何 开 始 变 得 
美丽 的 ， 变 化 是 由 外 及 里 的 ， 有 了 漂亮 的 外 表 才 有 内 心 的 实质 变化 ， 如 
代码 清单 31-10 所 示 。 








代码 清单 31-10 外 形 美 化 


public class BeautifyAppearance extends Decorator { 

// 要 美化 谁 

public BeautifyAppearance(Swan _swan)t 
super(_swan); 


} 
// 外 表 美 化 处 理 


























@Override 
public void desAppaearance( ){ 

System.out,printJln(" 外 表 是 纯 白 色 的 ， 非 常 疮 人 喜爱 ! "); 
} 

















丑小鸭 最 后 发 现 目 己 还 能 飞行 ， 这 是 一 个 行为 突破 ， 是 对 原 有 行 
为 “不 会 飞行 ”的 一 种 强化 ， 如 代码 清单 31-11 所 示 。 


代码 清单 31-11 强化 行为 


public class StrongBehavior extends Decorator { 

// 强 化 谁 

public StrongBehavior(Swan _swan)t{ 
super(_swan); 








} 

// 会 飞行 了 

public void fly()t{ 
System.out.println(" 会 飞行 了 ! "); 

} 


所 有 的 故事 元 素 我 们 都 具备 了 ， 就 等 有 人 来 讲 故事 了 ， 场 景 类 如 代 
码 清 单 31-12 所 示 。 


代码 清单 31-12 场景 类 


public class Client { 

public static void main(String[|] args) { 
// 很 久 很 久 以 前 ， 这 里 有 一 个 丑陋 的 小 鸭子 
System,out.,.printlLn("=== 很 久 很 久 以 前 ， 这 里 有 一 只 丑陋 的 小 鸭 : 
Swan duckling = new UglyDuckling(); 
// 展 示 一 下 小 蝎子 
duckling.desAppaearance(); // 小 鸭子 的 外 形 
duckling ,cry(); // 小 鸭子 的 叫 声 
duckling.fly(); // 小 鸭子 的 行为 
System.out.println("\n=== 小 卜 子 终于 发 现 自己 是 一 只 天 鹅 ==== 
// 首 先 外 形变 化 了 
duckling = new BeautifyAppearance(duckling); 
// 其 次 行为 也 发 生 了 改变 




















duckling = new StrongBehavior(duckling); 
// 虽 然 还 是 叫 丑 小 有 鸭 ， 但 是 已 经 发 生 了 很 大 变化 
duckling,desAppaearance(); /7/ 小 鸭子 的 新 外 形 
duck1ling,cry();， /小 鸭子 的 新 叫 声 
duckling,fly()， /小 鸭子 的 新 行为 





ww 


运行 结果 如 下 所 示 : 














=== 很 久 很 久 以 前 ， 这 里 有 一 只 丑陋 的 小 鸭子 === 








外 形 是 脏 今 今 的 白色 ， 毛 莹 营 的 大 脑袋 














叫 声 是 克 噜 一 一 元 噜 一 一 克 叭 











=== 小 鸭子 终于 发 现 自己 是 一 只 天 鹅 ==== 


外 表 是 纯 白 色 的 ， 非 常 荐 人 喜爱 ! 





叫 声 是 元 噜 一 一 元 噜 一 一 克 叭 





会 飞行 了 ! 


使 用 装饰 模式 描述 丑小鸭 凡 变 的 过 程 是 如 此 简单 ， 它 关注 了 对 象 功 
能 的 强化 ， 是 对 原始 对 象 的 行为 和 属性 的 修正 和 加 强 ， 把 原本 被 人 歧 
视 、 冷 落 的 丑小鸭 通过 两 次 强化 处 理 最 终 转 变 为 受 人 喜爱 、 鲜 莫 的 白天 
揭 。 


31.2.2 用 适配器 模式 实现 壬 小 鸭 


采用 运 配器 模式 实现 丑小鸭 变 成 日 天 狼 的 过 程 要 从 鸭 妈 妈 的 角度 来 


分 析 ， 鸭 妈妈 有 5 个 孩子 ， 它 认为 这 5 个 孩子 都 是 她 的 后 代 ， 都 是 鸭 类 ， 
但 是 实际 上 是 有 一 只 《也 就 是 丑小鸭 ) 不 是 真正 的 鸭 类 ， 她 是 一 只 小 白 
天 鹅 ， 就 像 《 木 兰 辞 》 中 说 的 “ 雄 人 兔 脚 扑 朔 ， 肉 倪 眼 迷离 。 双 人 免 傍 地 
走 ， 安 能 辨 我 是 雄 肉 ? ?同样 ， 因 为 太 小 ， 差 别 太 细微 ， 很 难 分 辨 ， 导 
致 鸭 妈 妈 认 为 她 是 一 只 鸭子 ， 从 鸭子 的 审美 观 来 看 ， 丑 小 鸭 是 丑陋 的 。 
通过 分 析 ， 我 们 要 做 的 就 是 要 设计 两 个 对 象 : 鸭 和 天 独 ， 然 后 鸭 妈 妈 把 
一 只 天 铬 看 成 了 小 鸭子 ， 最 终 时 间 到 来 的 时 候 丑 小 鸭 变 成 了 白天 儿 。 我 
们 来 看 类 图 ， 如 图 31-4 所 示 。 


Client 
1 
[| 














<<mterface>> 
Duck 
4 
+vold cry() 
+vold desAppearance() 
+vold desBehavior() 


图 31-4 适配器 模式 实现 丑小鸭 


类 图 非常 人 简单， 我们 定义 了 两 个 接口 : 鸭 类 接口 和 天 鹅 类 接口 ， 然 
后 建立 了 一 个 适配器 UglyDuckling， 把 一 只 白天 笋 封 装 成 了 小 鸭子 。 我 
们 来 看 代码 ， 先 看 鸭 类 接口 ， 如 代码 清单 31-13 所 示 。 





代码 清单 31-13 了 鸭 类 接口 


public interface Duck { 
// 会 叫 
public void cry(); 
// 鸭 子 的 外 形 
public void desAppearance( ) ， 
// 描 述 鸭 子 的 其 他 行为 


public void desBehavior(); 

















了 鸭 类 有 3 个 行为 ， 一 个 是 鸭 会 叫 ， 一 个 是 外 形 摘 述 ， 还 有 一 个 是 纤 
合 性 的 其 他 行为 描述 ， 例 如 会 游泳 等 。 我 们 来 看 鸭 妈 妈 的 4 个 正宗 孩 
子 ， 如 代码 清单 31-14 所 示 。 


代码 清单 31-14 小 鸭子 


public class Duckling implements Duck { 
public void cry() { 
System.out,printJIn(" 叫 声 是 嘎 一 嘎 一 喷 " ) ; 











public void desAppearance() { 
System.out.println(" 外 形 是 黄白 相间 ， 嘴 长 "); 


} 

// 鸭 子 的 其 他 行为 ， 如 游泳 

public void desBehavior(){ 
System,out.printlLn(" 会 游泳 ") ， 

} 

















只 正宗 的 小 鸭子 形象 已 经 清晰 地 定义 出 来 了 。 芍 妈妈 还 有 一 个 孩 








子 ， 就 是 另类 的 丑小鸭 ， 她 实际 是 一 只 白天 鹅 。 我 们 先 定义 出 白天 鹅 ， 
如 代码 清单 31-15 所 示 。 


代码 清单 31-15 白天 鹅 


public class WhiteSwan implements Swan { 
// 白 天 和 忽 的 叫 声 
public void cry() { 
System.out,printJln(" 叫 声 是 克 噜 一 克 噜 一 克 噜 " ) ， 


} 

// 白 天 鹅 的 外 形 

public void desAppaearance( ) 
System.out .printLn(" 外 形 是 纪 


} 

// 天 和 的 是 能 够 飞行 的 

public void fly() { 
System.out.println(" 能 够 飞行 " )， 

} 














Cer 





白色 ， 若 人 喜爱 " )， 





但 是 ， 鸭 妈妈 却 不 认为 目 己 这 个 为 类 的 孩子 是 白天 鹅 ， 它 从 目 己 的 
观点 出 发 ， 认 为 她 很 丑陋 ， 有 但 目 己 的 脸面 ， 于 是 驱赶 她 一 一 了 鸭 妈妈 把 
这 只 小 天 鹅 误 认 为 一 只 鸭 。 我 们 来 看 实现 ， 如 代码 清单 31-16 所 示 。 








代码 清单 31-16 把 白天 鹅 当 做 小 鸭子 看 待 


public class UglyDuckling extends WhiteSwan implements Duck { 
// 丑 小 鸭 的 叫 声 
public void cry() { 
super .cry( ); 


3 

// 丑 小 鸭 的 外 形 

public void desAppearance() { 
super .desAppaearance( ); 


// 丑 小 鸭 的 其 他 行为 
public void desBehavior()t{ 
// 丑 小 鸭 不 仅 会 游泳 


System.out.println(" 会 游泳 ")， 
// 还 会 飞行 
super .fly(); 


天 和 切 被 看 成 了 鸭子 ， 有 扩 棒 珍 天 物 的 感觉 。 我 们 再 来 创建 一 个 场景 


类 来 描述 


一 场景 ， 如 代码 清单 31-17 所 示 。 


代码 清单 31-17 场景 类 


public class Client { 
public static void main(String[] args) { 


CE 


// 鸭 妈妈 有 5 个 孩子 ， 其 中 4 个 都 是 一 个 模样 
System.out .printlin("=== 妈 妈 有 五 个 孩子 ， 其 中 四 个 模样 是 这 样 折 
Duck duck = new Duckling(); 

duck.cry(); // 小 鸭子 的 叫 声 

duck,desAppearance()， // 小 鸭子 的 外 形 
duck.desBehavior(); /7/ 小 鸭子 的 其 他 行为 
System.out.println("NXn=== 一 只 独特 的 小 鸭子 ， 模 样 是 这 样 的 : 
Duck uglyDuckling = new UglyDuckling(); 
uglyDuckling.cry(); // 丑 小 鸭 的 叫 声 
uglyDuckling.desAppearance(); // 丑 小 鸭 的 外 形 
uglyDuckling.desBehavior(); // 导 小 鸭 的 其 他 行为 
































运行 结果 如 下 所 示 : 


=== 妈 妈 有 5 个 孩子 ， 其 中 4 个 模样 是 这 样 的 ，=== 





叫 声 是 嘎嘎 嘎 


外 形 是 黄白 





会 游泳 



































相间 ， 嘴 长 




















=== 一 只 独特 的 小 鸭子 ， 模 样 是 这 样 的 : === 











叫 声 是 元 哈 


克 噜 一 一 克 史 


外 形 是 纯 白 色 ， 若 人 喜爱 





会 游泳 


能 够 飞行 





可 怜 的 小 天 和 切 被 认为 是 一 只 丑陋 的 小 鸭子 ， 造 物 和 弄 人 呀 ! 采用 适 配 
器 模式 讲述 丑小鸭 的 故事 ， 我 们 首先 观察 到 的 是 鸭 与 天 鹅 的 不 同 点 ， 建 
并 了 不 同 的 接口 以 实现 不 同 的 物种 ， 然 后 在 需要 的 时 候 根据 故事 情 
节 ) 把 一 个 物种 伪装 成 男 外 一 个 物种 ， 实 现 不 同 物种 的 相同 处 理 过 程 ， 
这 如 是 适配器 模式 的 设计 意图 。 


31.2.3 最 佳 实 践 


我 们 用 两 个 模式 实现 了 丑小鸭 的 美丽 赔 变 。 我 们 发 现 : 这 两 个 模式 
有 较 多 的 不 同 扩 。 


e 意图 不 同 








装饰 模式 的 意图 是 加 强 对 象 的 功能 ， 例 子 中 就 是 把 一 个 层 弱 的 小 天 
鹅 强化 成 了 一 个 美丽 、 自 信和 的 白天 和 殷 ， 它 不 改变 类 的 行为 和 属性 ， 只 是 
增加 (当然 了 ,减弱 类 的 功能 也 是 可 能 存在 的 ) 功能， 使 美丽 更 加 美 
丽 ， 强 壮 更 加 强壮 ， 安 全 更 加 安全 ;而 适 配 费 模式 关注 的 则 是 转化 ， 它 
的 主要 意图 是 两 个 不 同 对 象 之 间 的 转化 ， 它 可 以 把 一 个 天 笋 转化 为 一 个 
小 鸭子 看 待 ， 也 可 以 把 一 只 小 鸭子 看 成 是 一 只 天 故 ( 那 估计 要 在 小 鸭子 











的 背 上 装 个 螺旋 桨 了 )， 它 关注 转换 。 

e 施 与 对 象 不 同 

装饰 模式 闭 饰 的 对 象 必须 是 目 己 的 同宗 ， 也 就 是 相同 的 接口 或 父 
类 ， 只 要 在 具有 相同 的 属性 和 行为 的 情况 下 ， 才 能 比较 行为 是 增加 还 是 


减弱 ;， 适 配 占 模式 则 必须 是 两 个 不 同 的 对 象 ， 因 为 它 着 重 于 转换 ， 只 有 
两 个 不 同 的 对 象 才 有 转换 的 必要 ， 如 果 是 相同 对 象 还 转换 什么 ?|! 





e 场景 不 同 


装饰 模式 在 任何 时 候 都 可 以 使 用 ， 只 要 是 想 增 强 类 的 功能 ， 而 适 配 
需 模 式 则 是 一 个 补救 模式 ， 一 般 出 现在 系统 成 熟 或 已 经 构建 完毕 的 项 目 
中 ， 作 为 一 个 紧急 处 理 手段 采用 。 


e 扩展 性 不 同 


装饰 模式 很 容易 扩展 ! 今天 不 用 这 个 修饰 ， 好， 去 掉 ; 明天 想 再 使 
用 ， 好 ， 加 上 。 这 都 没有 问题 。 而 且 装 饰 类 可 以 继续 扩展 下 去 ， 但 是 适 
配器 模式 就 不 同 了 ， 它 在 两 个 不 同 对 象 之 间架 起 了 一 座 沟通 的 桥架 ， 建 
立 容易 ， 去 摊 就 比较 困难 了 ， 需 要 从 系统 整体 考 谍 是 人 否 能 够 撤销 。 





第 32 章 ”行为 类 模式 大 PK 


行为 类 模式 包括 贡 任 链 模 式 、 命 令 模 式 、 解 释 融 模式 、 友 代 器 模 
式 、 中 介 者 模式 、 备 起 录 模 式 、 观 察 者 模式 、 状 态 模式 、 筑 略 模 式 、 模 
板 方 法 模式 、 访 问 者 模式 。 该 组 真 可 谓 是 人 才 济 济 ， 局 手 如 云 。 行 为 类 
模式 的 11 个 模式 基本 上 都 是 大 家 和 耳 亢 能 详 的 ， 而 且 它 们 之 间 还 有 很 多 的 
相似 点 ， 特 别 是 一 些 扩展 部 分 束 更 加 相似 了 ， 我 们 挑选 几 个 比较 重要 的 
模式 进行 对 比 说 明 。 


32.1 命令 模式 VS 策略 模式 





命令 模式 和 策略 模式 的 类 图 确实 很 相似 ， 只 是 命令 模式 多 了 一 个 接 
收 者 (Receiver) 角色 。 它 们 虽然 同 为 行为 类 模式 ,但 是 两 者 的 区 别 还 
征 很 明显 的 。 策 略 模式 的 意图 是 封装 算法 ， 它 认为 “算法 ”已 经 是 一 个 完 
整 的 、 不 可 拆 分 的 原子 业务 注意 这 里 是 原子 业务 ， 而 不 是 原子 对 
象 ) ， 即 其 意图 是 让 这 些 算法 独立 ， 并 且 可 以 相互 蔡 换 ， 让 行为 的 变化 
独立 于 拥有 行为 的 客户 ; 而 命令 模式 则 是 对 动作 的 解 厢 ， 把 一 个 动作 的 
执行 分 为 执行 对 象 〈 接 收 者 角色 ) 、 执 行 行为 《命令 角色 ) ， 让 两 者 相 
互 独立 而 不 相互 影响 。 

















我 们 从 一 个 相同 的 业务 需求 出 发 ， 按 照 命令 模式 和 集 略 模式 分 别 设 
计 出 一 套 实现 ， 来 看 看 它们 的 侧重 点 有 什么 不 同 。zip 和 gzip 文 件 格 式 相 
信 大 家 都 很 熟悉 ， 它 们 是 两 种 不 同 的 压缩 格式 ， 我 们 今天 就 来 对 一 个 目 
录 或 文件 实现 两 种 不 同 的 压缩 方式 : zip 压 缩 和 gzip 压 缩 (这 里 的 压缩 指 
的 是 压 纵 和 解压 缩 两 种 对 应 的 操作 行为 ， 下 同 ) 。 实 现 这 两 种 压缩 格式 
有 什么 意义 呢 ? 有 意义 ! 一 是 zip 格 式 〈.zip 后 组) 是 Windows 操 作 系统 
常用 的 压缩 格式 ，gzip 格 式 〈.gz 后 级 ) 是 *nix 系 统 常用 的 压缩 格式 ; 二 
是 JDK 提 供 了 对 zip 和 gzip 文 件 的 操作 包 ， 非 常 容易 实现 文件 的 压缩 和 人 解 
压缩 操作 。 














下 面 我 们 来 实现 不 同 格式 的 压缩 和 解压 缩 功 能 。 
32.1.1 策略 模式 实现 压缩 算法 

使 用 策略 模式 实现 压缩 算法 非常 简单 ， 也 是 非常 标准 的 ， 类 图 如 图 
32-1 所 示 。 


在 类 图 中 ， 我 们 的 侧重 点 是 zip 压 缩 算法 和 gzip 压 缩 算 法 可 以 互相 蔡 
换 ， 一 个 文件 或 者 目录 可 以 使 用 zip 压 缩 ， 也 可 以 使 用 gzip 压 缩 ， 选 择 哪 
种 压缩 算法 是 由 高 层 模块 《实际 操作 者 ) 决定 的 。 我 们 来 看 一 下 代码 实 
现 。 先 看 抽象 的 压缩 算法 ， 如 代码 清单 32-1 所 示 。 

























<<interface>> 
Algorithm 





+boolean compress(String source, String to) 


+boolean uncompress(Strmg source, String to) 













+boolean compress(String source, String to) 
+boolean uncompress(String source, String to) 


lee 


zip 压 缩 算法 





图 32-1 策略 模式 实现 压缩 算法 的 类 图 


代码 清单 32-1 抽象 压缩 算法 


public interface Algorithm { 
// 压 缩 算法 
public boolean compress(String source,String to) 
// 解 压缩 算法 
public boolean uncompress(String source,String to); 








每 一 个 算法 要 实现 两 个 功能 : 压缩 和 解压 缩 ， 传 递 进来 一 个 绝对 路 
径 source，compress 把 它 压缩 到 to 目录 下 ，uncompress 则 进行 反 回 操作 
一 一 解压 缩 ， 这 两 个 方法 一 定 要 成 对 地 实现 ， 为 什么 呢 ? 用 gzip 解 压缩 
算法 能 解 开 zip 格 式 的 压缩 文件 吗 ? 我 们 分 别 来 看 两 种 不 同 格式 的 压缩 
算法 ，zip、8gzip 压 缩 算法 分 别 如 代码 清单 32-2、 代 码 清单 32-3 所 示 。 


代码 清单 32-2 zip 压 缩 算法 


public class Zip implements Algorithm { 





//zip 格 式 的 压缩 算法 
public boolean compress(String source, String to) { 
System.out.println(source + " -->" +to + " ZIP 压缩 成 


return true; 


} 

//zip 格 式 的 解压 缩 算 法 

public boolean uncompress(String source,String to)t{ 
System.out.println(source + " -->" +to + " ZIP 解 压缩 
return true; 








代码 清单 32-3 gzip 压 缩 算法 


public class Gzip implements Algorithm { 





//gzip 的 压缩 算法 
public boolean compress(String source, String to) { 
System.out,println(source + " --> " +to + " GZIP 压 缩 上 


return true; 





} 

//gzip 解 压缩 算法 

public boolean uncompress(String source,String to)t{ 
System.out.printin(source + " -->" +to + " GZIP 解 压 乡 
return true 


这 两 种 压缩 算法 实现 起 来 都 很 简单 ，Java 对 此 都 提供 了 相关 的 API 
操作 ， 这 里 残 不 再 提供 详细 的 编写 代码 ， 读 者 可 以 参考 JDK 自 己 进行 实 
现 ， 或 者 上 网 搜索 一 下 ， 网 上 有 太 多 类 似 的 源 代码 。 





两 个 具体 的 算法 实现 了 同一 个 接口 ， 完 全 遵循 依赖 倒转 原则 。 我 们 
再 来 看 环境 角色 ， 如 代码 清单 32-4 所 示 。 


代码 清单 32-4 环境 角色 


public class Context { 

// 指 向 抽象 算法 

private Algorithm al; 

// 构 造 函 数 传递 具体 的 算法 

public Context(Algorithm _al)t{ 
this.al = al; 


} 

// 执 行 压缩 算法 

public boolean compress(String source,String to)t{ 
return al.compress(source, to); 


} 

// 执 行 解压 缩 算法 

public boolean uncompress(String source,String to)t{ 
return al.uncompress(source, to); 

















非常 简单 ， 指 定 一 个 算法 ， 执 行 该 算法 ， 一 个 标准 的 策略 模式 
完毕 了 。 请 读者 注意 ， 这 里 虽然 有 两 个 算法 Zip 和 Gzip， 但 是 对 


各 
洲 
| 
时 他 


调用 者 来 说 ， 这 两 个 算法 没有 本 质 上 的 区 别 ， 只 是 “形式 ?上 不 同 ， 什 么 
意思 呢 ? 从 调用 者 来 看 ， 使 用 哪 一 个 算法 都 无 所 谓 ， 两 者 完全 可 以 互 
换 ， 甚 至 用 一 个 算法 蔡 代 另外 一 个 算法 。 我 们 继续 看 调用 者 是 如 何 调用 
的 ， 如 代码 清单 32-5 所 示 。 


代码 清单 32-5 场景 类 


public class Client { 
public static void main(String[|] args) { 
// 定 义 环境 角色 
Context context ， 
// 对 文件 执行 Zip 压缩 算法 

















System.out.printLn("======== 执 行 算法 ========" ) ; 
context = new Context(new Zip()); 
pA 

* 算 法 替换 


* context = new Context(new Gzip()); 
* 


pA 

// 执 行 压缩 算法 
context.compress("c:\\windows","d:\\windows.zip"); 
// 执 行 解压 缩 算 法 


context.uncompress("c:\\windows.zip","d:\\windows"); 











-一 


运行 结果 如 下 所 示 : 





ci:\windows --> d:\windows.zip ZIP 压缩 成 功 ! 


cwindows.zip --> d:\windows ZIP 解压 缩 成 功 ! 


要 使 用 gzip 算 法 吗 ? 在 客户 端 〈Client) 上 把 注释 删 掉 就 可 以 了 ， 其 
他 的 模块 根本 不 受 任何 影响 ， 策 略 模式 关心 的 是 算法 是 否 可 以 相互 葵 


换 。 策 略 模式 虽然 简单 ， 但 是 在 项 目 组 使 用 得 非常 多 ， 可 以 说 随手 拓 来 
就 是 一 个 策略 模式 。 





32.1.2 命令 模式 实现 压缩 算法 





命令 模式 的 主旨 是 封装 命令 ， 使 请 求 者 与 实现 者 解 耦 。 例 如 ， 到 饭 
店 点 菜 ， 客 人 《请求 者 ) 通过 服务 员 《〈 调 用 者 ) 向 厨师 〈 接 收 者 ) 发 送 
了 订单 (行为 的 请 求 )， 该 例子 就 是 通过 封装 命令 来 使 请 求 者 和 接收 者 
解 厢 。 我 们 继续 来 看 压缩 和 解压 缩 的 例子 ， 怎 么 使 用 命令 模式 来 完成 该 
需求 呢 ? 我 们 先 画 出 类 图 ， 如 图 32-2 所 示 。 





类 图 看 着 复杂 ， 但 是 还 是 一 个 典型 的 命令 模式 ， 通 过 定义 具体 命令 
完成 文件 的 压缩 、 解 压缩 任务 ， 注 意 我 们 这 里 对 文件 的 每 一 个 操作 都 是 
封装 好 的 命令 ， 对 于 给 定 的 请 求 ， 命 令 不 同 ， 处 理 的 结果 当然 也 不 同 ， 
这 就 是 命令 模式 要 强调 的 。 我 们 先 来 看 抽象 命令 ， 如 代码 清单 32-6 所 


钞 。 


代码 清单 32-6 抽象 压缩 命令 


public abstract class AbstractCmd { 
// 对 接收 者 的 引用 
protected IReceiver zip = new ZipReceiver(); 
protected IReceVer gzip = new GzipReceiver(); 
// 抽 象 方法 ， 命 令 的 具体 单元 


public abstract boolean execute(String source,String to); 










<<imterface>> 
IReceiver 
[rr | 
= 了 | 
ER 
| | 
AbstractCmd 


#IReceiver zip = new ZipReceiver() 
#IReceiver gzip = new GzipReceiver() 















+boolean execute(String source, String to) 





GzipUncompressCmd 





ZipCompressCmd| | ZipUncompressCmd| | GzipCompressCmd 


图 32-2 命令 模式 实现 压缩 算法 的 类 图 

















抽象 命令 定义 了 两 个 接收 者 的 引用 : zip 接 收 者 和 gzip 接 收 者 ， 大 家 
可 以 想象 一 下 这 两 个 “受气 包 ”， 它 们 完全 是 受众 ， 人 家 让 它 干 啥 它 就 干 
喻 ， 上 有 具体 使 用 哪个 接收 者 是 命令 决定 的 。 具 体 命 令 有 4 个 : zip 压 缩 、zip 
解压 缩 、gzip 压 缩 、gzip 解 压缩 ， 分 别 如 代码 清单 32-7、32-8、32-9、 





32-10 所 示 。 


代码 清单 32-7 zip 压 缩 命 令 


public class ZipCompressCmd extends AbstractCmd { 
public boolean execute(String source,String to) { 
return super.zip.compress(source, to); 


} 


代码 清单 32-8 zip 解 压缩 命令 


public class ZipUncompressCmd extends AbstractCmd { 
public boolean execute(String source,String to) { 
return super.zip.uncompress(source, to); 
} 


代码 清单 32-9 gzip 压 缩 命令 


public class GzipCompressCmd extends AbstractCmd { 
public boolean execute(String source,String to) { 
return super.gzip.compress(source, to); 
} 


代码 清单 32-10 gzip 解 压缩 命令 


public class GzipUncompressCmd extends AbstractCmd { 
public boolean execute(String source,String to) { 
return super.gzip.uncompress(source, to); 
} 


它们 非常 简单 ， 都 只 有 一 个 方法 ， 坚 决 地 执行 命令 ,使 用 了 委托 的 
方式 ， 由 接收 者 来 实现 。 我 们 再 来 看 抽象 接收 者 ， 如 代码 清单 32-11 所 


帮 \。 


代码 清单 32-11 抽象 接收 者 


public interface IReceiver { 
// 压 缩 
public boolean compress(String source,String to); 
// 解 压缩 
public boolean uncompress(String source,String to); 





抽象 接收 者 与 集 略 模 式 的 抽象 策略 完全 相同 ， 具 体 的 实现 也 完全 相 
同 ， 只 是 类 名 做 了 改动 ， 我 们 和 来 看 zip 压 缩 的 实现 ， 如 代码 清单 32-12 


所 示 。 


代码 清单 32-12 zip 接 收 者 


public class ZipReceiver implements IReceiver { 





//zip 格 式 的 压缩 算法 
public boolean compress(String source, String to) { 
System.out.println(source + " --> " +to + " ZIP 压缩 成 


return true; 


} 

//zip 格 式 的 解压 缩 算 法 

public boolean uncompress(String source,String to)t{ 
System.out.println(source + " -->" +to + " ZIP 解 压缩 
return true; 

















} 

这 就 是 一 个 具体 动作 执行 者 ， 它 在 策略 模式 中 是 一 个 具体 的 算法 ， 
关心 的 是 是 否 可 以 被 蔡 换 ， 而 在 命令 模式 中 ， 它 则 是 一 个 具体 、 真 实 的 
命令 执行 者 。 我 们 再 来 看 gzip 接 收 者 ， 如 代码 清单 32-13 所 示 。 


代码 清单 32-13 gzip 接 收 者 


public class GzipReceiver implements IReceiver { 
//gzip 的 压缩 算法 
public boolean compress(String source, String to) { 
System.out,println(source + " --> " +to + " GZIP 压 缩 上 
return true; 








} 

//gzip 解 压缩 算法 

public boolean uncompress(String source,String to)t{ 
System.out.printin(source + " --> " +to + " GZIP 解 压 乡 
return true 











大 家 可 以 这 样 思 考 这 个 问题 ， 接 收 者 就 是 厨房 的 厨师 ， 有 基体 要 哪个 





厨师 做 这 道 菜 则 是 餐馆 的 规章 制度 已 经 明确 的 ， 你 让 专 做 粤菜 的 师傅 做 
一 个 币 株 鱼 头 ， 能 做 出 好 沫 吗 ? 在 命令 模式 中 ， 惑 是 在 抽象 命令 中 定义 
了 接收 者 的 引用 ， 然 后 在 具体 的 实现 类 中 确定 要 让 哪个 接收 者 进行 处 
理 。 这 惑 好 比 是 客人 点 菜 : 我 要 一 个 制 株 鱼 头 ， 这 就 是 一 个 命令 ， 然 后 
服务 员 (Inovker) 接收 到 这 个 命令 后 ， 束 开始 执行 ， 把 这 个 命令 指定 给 
具体 的 执行 者 执行 。 





当然 了 ， 接 收 者 这 部 分 还 可 以 这 样 设计 ， 即 按照 职责 设计 接收 者 ， 
比如 压缩 接收 者 、 解 压缩 接收 者 ， 但 接口 需要 稍稍 改动 ， 如 代码 清单 


32-14 所 示 。 


代码 清单 32-14 依照 职责 设计 的 接收 者 接口 


public interface IReceiver { 
// 执 行 zip 命 令 
public boolean zipExec(String source,String to); 
// 执 行 gzip 命 令 
public boolean gzipExec(String source String to); 





接收 者 接口 只 是 定义 了 每 个 接收 者 都 必须 完成 zip 和 gzip 相 关 的 两 个 
逻辑 ， 有 多 少 个 职责 就 有 多 少 个 实现 类 。 我 们 这 里 只 有 两 个 职责 : 压缩 
和 解压 缩 ， 分 别 如 代码 清单 32-15、32-16 所 示 。 


代码 清单 32-15 压缩 接收 者 


public class CompressReceiver implements IReceiver { 
// 执 行 gzip 压 缩 命令 
public boolean gzipExec(String source, String to) { 
System.out.printin(source + " --> " +to + " GZIP 压 缩 


return true; 


} 

// 执 行 zip 压 缩 命 令 

public boolean zipExec(String source, String to) 
System.out.println(source + " -->" +to + " ZIP 压缩 成 
return true 


代码 清单 32-16 解压 缩 接收 者 


public class UncompressReceiver implements IReceiver { 
// 执 行 gzip 解 压缩 命令 
public boolean gzipExec(String source, String to) { 
System.out.printin(source + " -->" +to + " GZIP 人 解压 
return true; 


} 

// 执 行 zip 解 压缩 命令 

public boolean zipExec(String source, String to) { 
System.out.println(source + " -->" +to + " ZIP 解 压缩 
return true; 





剩 下 的 工作 残 是 对 抽象 命令 、 具 体 命 令 稍 作 修 改 ， 这 里 不 再 袭 述 。 
为 什么 要 在 这 里 增加 一 个 分 文 描述 呢 ? 这 是 为 了 与 策略 模式 对 比 ， 在 命 
令 模式 中 ， 我 们 可 以 把 接收 者 设计 得 与 策略 模式 的 算法 相同 ， 也 可 以 不 
相同 。 我 们 按照 职责 设计 的 接口 怠 不 适用 于 策略 模式 ， 不 可 能 封装 一 个 
叫做 压缩 的 算法 类 ， 然 后 在 类 中 提供 两 种 不 同 格 式 的 压缩 功能 ， 这 违背 
了 策略 模式 的 意图 一 一 封装 算法 ， 为 什么 呢 ? 如 打 要 增加 一 个 rar 压 缩 算 
法 ， 该 怎么 办 呢 ? 修改 抽象 算法 ? 这 是 绝对 不 允许 的 ! 那 为 什么 命令 模 
式 就 是 允许 的 呢 ?” 因 为 命令 模式 着 重 于 请 求 者 和 接收 者 解 厢 ， 你 管 我 接 
收 者 怎么 变化 ， 只 要 不 影响 请 求 者 就 成 ， 这 才 是 命令 模式 的 意图 。 





























命令 、 接 收 者 都 具备 了 ， 我 们 再 来 封装 一 个 命令 的 调用 者 ， 如 代码 
清单 32=:17 所 示 。 


代码 清单 32-17 调用 者 


public class Invoker { 
// 抽 象 命令 的 引用 
private AbstractCmd cmd ; 
public Invoker(AbstractCmd _cmd){ 
this.cmd = _cmd; 


} 

// 执 行 命令 

public boolean execute(String source,String to)t{ 
return cmd.execute(source, to); 

} 


调用 者 非常 简单 ， 只 负 贡 把 命令 癌 后 传递 ， 当 然 这 里 也 可 以 进行 一 
定 的 拦截 处 理 ， 我 们 暂时 用 不 到 惑 不 做 处 理 了 。 我 们 来 看 场景 类 是 如 何 
描述 这 个 场景 的 ， 如 代码 清单 32-18 所 示 。 





代码 清单 32-18 场景 类 


public class Client { 
public static void main(String[|] args) { 
// 定 义 一 个 命令 ,压缩 一 个 文件 
Abstractcmd cmd = new ZipCompressCmd(); 
/2 
* 想 换 一 个 ?执行 解压 命令 
* AbstractCmd cmd = new ZipUncompresscmd(); 
yA 
// 定 义 调用 者 
Invoker invoker = new Invoker(cmd); 
// 我 命令 你 对 这 个 文件 进行 压缩 
System,out.printlLn("======== 执 行 压缩 命令 ========" ) ; 
Invoker .execute("c:\\windows", "d:\\windows.zip"); 














想 新 增 一 个 命令 ? 当然 没有 问题 ， 只 要 重新 定义 一 个 命令 就 成 ， 命 
令 改变 了 ， 高 层 模块 只 要 调用 它 吏 成 。 请 注意 ， 这 里 的 程序 还 有 点 从 
缺 ， 没 有 与 文件 的 后 绥 名 绑 定 ， 不 应 该 出 现 使 用 zip 压 缩 命 令 产生 一 
个 .gzip 后 级 的 文件 名 ， 读 者 在 实际 应 用 中 可 以 考虑 与 文件 后 级 名 之 间 建 
并 关联 。 





通过 以 上 例子 ， 我 们 看 到 命令 模式 也 实现 了 文件 的 压缩 、 解 压缩 的 
功能 ， 它 的 实现 是 关注 了 命令 的 封 贸 ， 是 请 求 者 与 执行 者 彻底 分 开 ， 看 
看 我 们 的 程 计 ， 执 行者 根本 就 不 用 了 解 命 令 的 具体 执行 者 ， 它 只 要 封装 
一 个 命令 一 一 “给 我 用 zip 格 式 压 缩 这 个 文件 ?就 可 以 了 ， 有 具体 由 谁 来 执 
行 ， 则 由 调用 者 负责 ， 如 此 设计 后 ， 束 可 以 保证 请 求 者 和 执行 者 之 间 可 
以 相互 独立 ， 各 上 自发 展 而 不 相互 影响 。 











同时 ， 由 于 是 一 个 命令 模式 ， 接 收 者 的 处 理 可 以 进行 排队 处 理 ， 在 
排队 处 理 的 过 程 中 ， 可 以 进行 撤销 处 理 ， 比 如 客人 点 了 一 个 亲 ， 厨 师 还 
没 来 得 及 做 ， 那 要 撤回 很 简单 ， 撤 回 也 是 命令 ， 这 是 琐 略 模式 所 不 能 实 
现 的 。 


3213 小 估 





策略 模式 和 命令 模式 相似 ， 特 别 是 命令 模式 退化 时 ， 比 如 无 接收 者 
(接收 者 非常 简单 或 者 接收 者 是 一 个 Java 的 基础 操作 ， 无 需 专门 编写 一 





个 接收 者 ) ， 在 这 种 情况 下 ， 命 令 人 模式 和 集 略 模式 的 类 图 完全 一 样 ， 代 
人 码 实现 也 比较 类 似 ， 但 是 两 者 还 是 有 区 别 的 。 











e 关注 点 不 同 





打上 略 模 式 关 注 的 是 算法 丛 换 的 问题 ， 一 个 新 的 算法 投产 ， 旧 算法 退 
休 ， 或 者 提供 多 种 算法 由 调用 者 自己 选择 使 用 ， 算 法 的 自由 更 丛 是 它 实 
现 的 要 点 。 换 句 话 说 ， 人 策略 模式 关注 的 是 算法 的 完整 性 、 封 装 性 ， 只 有 
具备 了 这 两 个 条 件 才 能 保证 其 可 以 自由 切换 。 








命令 模式 则 关注 的 是 解 厢 问 题 ， 如 何 让 请 求 者 和 执行 者 解 丰 是 
要 首先 解决 的 ， 解 耘 的 要 求 就 是 把 请 求 的 内 容 封 装 为 一 个 一 个 的 命 
由 接收 者 执行 。 由 于 封装 成 了 命令 ， 束 同 时 可 以 对 命令 进行 多 种 处 理 ， 
例如 撤销 、 记 录 等 。 


令 ， 


e 角色 功能 不 同 


在 我 们 的 例子 中 ， 策 略 模 陈 中 的 抽象 算法 和 有 具体 算法 与 命令 模式 的 
接收 者 非 第 相似， 但 是 它们 的 职责 不同。 策略 模式 中 的 具体 算法 是 负责 
一 个 完整 算法 逻辑 ， 它 是 不 可 再 拆 分 的 原子 业务 单元 ， 一 旦 变更 束 是 对 
算法 整体 的 变更 。 














而 命令 模式 则 不 同 ， 它 关注 命令 的 实现 ， 也 就 古 功 能 的 实现 。 例 如 
我 们 在 分 文中 也 提 到 接收 者 的 变更 问题 ， 它 只 影 啊 到 命令 族 的 变更 ， 对 





请 求 者 没有 任何 影响 ， 从 这 方面 来 说 ， 接 收 者 对 命令 负责 ， 而 与 请 求 者 
无 天。 命令 模式 中 的 接收 者 只 要 符合 六 大 设计 原则 ， 完 全 不 用 关心 它 是 
人 否 完 成 了 一 个 具体 逻辑 ， 它 的 影响 范围 也 仪 仪 是 抽象 命令 和 具体 命令 ， 

对 它 的 修改 不 会 扩散 到 模式 外 的 模块 。 


当然 ， 如 果 在 命令 模式 中 需要 指定 接收 者 ， 则 需要 考虑 接收 者 的 变 
化 和 封装 ， 例 如 一 个 老 顾 客 每 次 吃饭 都 点 同一 个 局 师 的 饭 染 ， 那 就 必须 
考虑 接收 者 的 抽象 化 问题 。 


e 使 用 场景 不 同 


策略 模式 适用 于 算法 要 求 变换 的 场景 ， 而 命令 模式 适用 于 解 耦 两 个 
有 紧 灯 合 关系 的 对 象 场合 或 者 多 命令 多 撤销 的 场景 





32.2 策略 模式 VS 状态 模式 


在 行为 类 设计 模式 中 ， 状 态 模 式 和 策略 模式 是 杀 兄 第 ， 两 者 非常 相 
似 ， 我 们 先 看 看 两 者 的 通用 类 图 ， 把 两 者 放 在 一 起 比较 一 下 ， 如 图 32-3 
所 示 。 
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图 32-3 策略 模式 〈 左 ) 和 状态 模式 〈 右 ) 的 通用 类 图 


两 个 类 图 非常 相似 ， 都 是 通过 Context 类 封装 一 个 具体 的 行为 ， 都 提 
供 了 一 个 封闭 的 方法 ， 是 高 扩展 性 的 设计 模式 。 但 根据 两 者 的 定义 ， 我 
们 发 现 两 者 的 区 别 还 是 很 明显 的 : 策略 模式 封装 的 是 不 同 的 算法 ， 算 法 
之 间 没 有 交互 ， 以 达到 算法 可 以 自由 切换 的 目的 ， 而 状态 模式 封装 的 是 
不 同 的 状态 ， 以 达到 状态 切换 行为 随 之 发 生 改变 的 目的 。 这 两 种 模式 虽 
然 都 有 变换 的 行为 ， 但 是 两 者 的 目标 却 是 不 同 的 。 我 们 举例 来 说 明 两 者 
的 不 同 反 。 














人 只 要 生 下 来 就 有 工作 可 做 ， 人 在 孩童 时 期 的 主要 工作 就 是 玩 亦 
(学 习 只 是 在 人 类 具有 了 精神 意识 行为 后 才 产 生 的 ); 成 人 时 期 的 主要 
工作 是 养活 自己 ， 然 后 为 社会 做 页 献 ， 老 年 时 期 的 主要 工作 就 是 享受 天 





伦 之 乐 。 按 照 策略 模式 来 分 析 ， 这 三 种 不 同 的 工作 方式 就 是 三 个 不 同 的 
具体 算法 ， 随 着 时 光 的 推移 工作 内 容 随 之 更 其， 这 和 对 一 堆 数组 的 冒 泡 
排序 、 快 速 排序 、 插 入 排序 一 样 ， 都 是 一 系列 的 算法 ， 而 按照 状态 模式 
进行 设计 ， 则 认为 人 的 状态 (孩童 、 成 人 、 老 人 ) 产生 了 不 同 的 行为 结 
果 ， 这 里 的 行为 都 相同 ， 痢 是 工作 ， 但 是 它们 的 实现 方式 确实 不 同 ， 也 
束 是 产生 的 结果 不 同 ， 看 起 来 束 像 是 类 改变 了 。 








32.2.1 策略 模式 实现 人 生 


下 面 按照 策略 模式 进行 设计 ， 先 来 看 类 图 ， 如 图 32-4 所 示 。 


这 是 非常 典型 的 集 略 模式 ， 没 有 太 多 的 玄机 ， 它 定义 了 一 个 工作 算 
法 ， 然 后 有 三 个 实现 类 : 孩童 工作 、 成 年 人 工作 和 老年 人 工作 。 我 们 来 
看 代码 ， 首 先 看 抽象 工作 算法 ， 如 代码 清单 32-19 所 示 。 


WorkAlgorithm 
vv 


UL | 
EL | +void work() 
















ChildWork AdultWork OldWork 


图 32-4 策略 模式 实现 人 生 的 类 图 


代码 清单 32-19 抽象 工作 算法 


public abstract class WorkAlgorithm { 
// 每 个 年 龄 段 都 必须 完成 的 工作 
public abstract void work(); 


无 论 如 何 ， 每 个 算法 都 必须 实现 work 方 法 ， 完 成 对 工作 内 容 的 定 
义 ， 三 个 具体 的 工作 算法 如 代码 清单 32-20、32-21、32-22 所 示 。 


代码 清单 32-20 孩童 工作 


public class Childwork extends WorkAlgorithm { 
// 小 孩 的 工作 
@Override 
public void work() { 
System.out.println(" 儿 章 的 工作 是 玩 而 !")， 





} 
} 
代码 清单 32-21 成 年 人 工作 
public class AdultWork extends WorkAlgorithm { 
// 成 年 人 的 工作 
@Override 


public void work() { 
System.out.println(" 成 年 人 的 工作 就 是 先 养活 自己 ， 然 后 为 社会 1 











} 
} 
代码 清单 32-22 老年 人 工作 
public class Oldwork extends WorkAlgorithm { 
// 老 年 人 的 工作 
@Override 


public void work() { 








System.out.println(" 老 年 人 的 工作 就 是 圣 受 天 伦 之 乐 !"); 


我 们 再 来 看 环境 角色 ， 如 代码 清单 32-23 所 示 。 


代码 清单 32-23 环境 角色 


public class Context { 
private WorkAlgorithm workMethod; 
public workAlgorithm getwork() { 
return workMethod; 


} 
public void setwork(WorkAlgorithm work) { 
this.workMethod = work; 


} 

// 每 个 算法 都 有 必须 具有 的 功能 

public void work(){ 
workMethod .work( ); 

} 














我 们 编写 一 个 场景 类 来 模拟 该 场景 ， 如 代码 清单 32-24 所 示 。 


代码 清单 32-24 场景 类 


public class Client { 

public static void main(String[] args) { 
// 定 义 一 个 环境 角 
Context context=new Context(); 
System.out.println("==== 儿 童 的 主要 工作 =====" )， 
context.setwork(new Childwork( )); 
context .work(); 
System.out.println("\n==== 成 年 人 的 主要 工作 =====" ); 
context.setwork(new AdultWwork( )); 
context .work(); 
System.out.println("\n==== 老 年 人 的 主要 工作 =====" )，; 
context.setwork(new Oldwork( )); 
context .work(); 


Ey 























在 这 里 我 们 把 每 个 不 同 的 工作 内 容 作为 不 同 的 算法 ， 分 别 是 孩童 工 
作 、 成 年 人 工作 、 老 年 人 工作 算法 ， 然 后 在 场景 类 中 根据 不 同 的 年 龄 段 
匹配 不 同 的 工作 内 容 ， 其 运行 结果 如 下 所 未: 








-==== 儿 童 的 主要 工作 ===== 


儿童 的 工作 是 玩 要 ! 











==== 成 年 人 的 主要 工作 ===== 








成 年 人 的 工作 就 是 先 养活 上 自己， 然后 为 社会 做 贡献 ! 








= 二 = 老生 人 前 二 本 下 人 > 





老年 人 的 工作 就 是 享受 天 伦 之 乐 ! 


通过 采用 策略 模式 我 们 实现 了 “工作 ”这 个 朱 略 的 三 种 不 同 算法 ， 算 
法 可 以 自由 切换 ， 到 搬 用 哪个 算法 由 调用 者 (局 层 模 块 ) 决定 。 策 略 模 
式 的 使 用 重点 是 算法 的 自由 切换 一 一 老 的 算法 退休 ， 新 的 算法 上 台 ， 对 
模块 的 整体 功能 没有 非常 大 的 改变 ， 非 第 灵活 。 而 如 末 想 要 增加 一 个 新 
的 算法 ， 比 如 未 出 生 坚 儿 的 工作 ， 只 要 继承 WorkAlgorithm 束 可 以 了 。 


32.2.2 状态 模式 实现 人 和 牛 
我 们 再 来 看 看 使 用 状态 模式 是 如 何 实 现 该 需求 的 。 随 着 时 间 的 变 


化 ， 人 的 状态 变化 了 ， 同 时 引起 了 人 的 工作 行为 改变 ， 完 全 符合 状态 模 
式 。 我 们 来 看 类 图 ， 如 图 32-5 所 示 。 



















tsetState(HumanState state) 
+void work() 
HumanState 
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+vold setHuman(Human human) 
+void work!) 
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AdultState 
| 
一 | 

图 32-5 状态 模式 实现 人 生 的 类 图 

这 与 生 略 模式 非常 相似 ， 基 本 上 束 是 几 个 类 名 称 的 修改 而 已 ， 但 是 
其 中 缠 藏 的 玄机 束 大 了 ， 看 看 代码 你 就 会 明白 。 我 们 先 来 看 抽象 状态 
类 ， 如 代码 清单 32-25 所 示 。 


代码 清单 32-25 人 的 抽象 状态 


public abstract class HumanState { 


// 指 向 一 个 具体 的 人 

protected Human human 

// 设 置 一 个 具体 的 人 

public void setHuman(Human _human)t 
this.human = _human; 


) 
// 不 管 人 是 什么 状态 都 要 工作 


public abstract void work(); 








抽象 状态 定义 了 一 个 具体 的 人 (human) 必须 进行 工作 (work) ， 
但 是 一 个 人 在 哪些 状态 下 完成 哪些 工作 则 是 由 子 类 来 实现 的 。 我 们 先 来 
看 孩童 状态 ， 如 代码 清单 32-26 所 示 。 


代码 清单 32-26 孩童 状态 


public class ChildState extends HumanStatet 
// 儿 童 的 工作 就 是 玩 要 
public void work(){ 
System.out.println(" 儿 童 的 工作 是 玩 夏 ! " ) ; 
super .human.setState(Human,ADULT_STATE ) ; 

















ChildState 类 代表 孩童 状态 ， 在 该 状态 下 的 工作 就 是 玩 亦 。 读 者 看 
独 可 能 有 点 惊奇 ， 在 work 方 法 中 为 什么 要 设置 下 一 个 状态 ? 因为 我 们 的 
状态 变化 都 是 单方 向 的 ， 从 孩童 到 成 年 人 ， 然 后 到 老年 人 ， 每 个 状态 转 
换 到 其 他 状态 只 有 一 个 方向 ， 因 此 会 在 这 里 看 到 work 有 两 个 职员 : 完成 
工作 逻辑 和 定义 下 一 状态 。 





我 们 再 来 看 成 年 人 状态 和 老年 人 状态 ， 分 别 如 代码 清单 32-27、32- 
28 所 示 。 


代码 清单 32-27 成 年 人 状态 


public class AdultState extends HumanState { 
// 成 年 人 的 工作 就 是 先 养活 自己 ， 然 后 为 社会 做 贡献 
@Override 
public void work() { 
System.out.println(" 成 年 人 的 工作 就 是 先 养活 自己 ， 然 后 为 社会 1 
Super ,human.setState(Human.0OLD_STATE ) ; 











代码 清单 32-28 老年 人 状态 


public class OldState extends HumanState { 
// 老 年 人 的 工作 就 是 享受 天 伦 之 乐 
@Override 
public void work() { 
System.out.println(" 老 年 人 的 工作 就 是 享受 天 伦 之 乐 !"); 
} 








每 一 个 HumanState 的 子 类 都 代表 了 一 种 状态 ， 虽 然 实 现 的 方法 名 
work 都 相同 ， 但 是 实现 的 内 容 却 不 同 ， 也 就 是 在 不 同 的 状态 下 行为 随 之 
改变 。 我 们 来 看 环境 角色 是 如 何 处 理 行 为 随 状 态 的 改变 而 改变 的 ， 如 代 
码 清单 32-29 所 示 。 








代码 清单 32-29 环境 角色 


public class Human { 
// 定 义 人 类 都 具备 哪些 状态 
public static final HumanState CHIILD_STATE = new Childstate 
public static final HumanState ADULT_STATE = new AdultStatel( 
public static final HumanState OLD_STATE = new OldState(); 
// 定 义 一 个 人 的 状态 
private HumanState state; 
// 设 置 一 个 状态 
public void setState(HumanState _state)t{ 
this.state = _state; 








this.state.setHuman(this); 


} 

// 人 类 的 工作 

public void work(){ 
this.state.work( ); 

} 





定义 一 个 Human 类 代表 人 类 ， 也 就 是 状态 模式 中 的 环境 角色 ， 每 个 
人 都 会 经 历 从 孩童 到 成 年 人 再 到 老年 人 这 样 一 个 状态 过 渡 〈 当 然 了 ， 老 
顽童 周伯通 的 情况 我 们 就 没有 考虑 进来 ) ， 随 着 状态 的 改变 ， 行 为 也 改 
变 。 我 们 来 看 场景 类 ， 如 代码 清单 32-30 所 示 。 





代码 清单 32-30 场景 类 


public class Client { 

public static void main(String[|] args) { 
// 定 义 一 个 普通 的 人 
Human human = new Human(); 
// 设 置 一 个 人 的 初始 状态 
human.setState(new ChildSstate()); 
System.out.println("==== 儿 童 的 主要 工作 =====" )， 
human .work( ); 
System.out.println("\n==== 成 年 人 的 主要 工作 =====" )，; 
human .work( ); 
System.out.println("\n==== 老 年 人 的 主要 工作 =====" ); 
human .work( ); 

















-一 


运行 结果 如 下 所 示 : 





==-= 儿 童 的 主要 工作 ===== 


儿童 的 工作 是 玩 页 ! 











= 成 年 人 的 主要 工作 := 











成 年 人 的 工作 就 是 先 养活 自己 ， 然 后 为 社会 做 贡献 ! 








= 第 入 的 证 要 诗作 = 





老年 人 的 工作 就 是 享受 天 伦 之 乐 ! 





运行 结果 与 策略 模式 相同 ， 但 是 两 者 的 分 析 角 上 度 是 大 相 径 庭 的 。 货 
略 模式 的 实现 是 通过 分 析 每 个 人 的 工作 方式 的 不 同 而 得 出 三 个 不 同 的 算 
法 人 逻辑， 状态 模式 则 是 从 人 的 生长 规律 来 分 析 ， 每 个 状态 对 应 了 不 同 的 
行为 ， 状 态 改变 后 行为 也 随 之 改变 。 从 以 上 示例 中 我 们 也 可 以 看 出 ， 对 
于 相同 的 业务 需求 ， 有 很 多 种 实现 方法 ， 问 题 的 重点 是 业务 关注 的 是 什 
么 ， 是 人 的 生长 规律 还 是 工作 逻辑 ? 找 准 了 业务 的 焦点 ， 才 能 选择 一 个 
好 的 设计 模式 。 











022 小 全 











从 例子 中 我 们 可 以 看 出 策略 模式 和 状态 模式 确实 非常 相似 ， 称 之 为 
杀 兄 第 亦 不 为 过 ， 但 是 这 两 者 还 是 存在 独 非常 大 的 兰 别 ， 而 且 也 是 很 容 
易 区 分 的 。 








e 环境 角色 的 职 贡 不同 


两 者 都 有 一 个 叫做 Context 环 境 角 色 的 类 ， 但 是 两 者 的 区 别 很 大 ， 货 
略 模式 的 环境 角色 只 是 一 个 委托 作用 ， 负 责 算法 的 蔡 换 ， 而 状态 模式 的 
环境 角色 不 仅仅 是 委托 行为 ， 它 还 具有 登记 状态 变化 的 功能 ， 与 具体 的 
状态 类 协作 ， 共 同 完成 状态 切换 行为 随 之 切换 的 任务 。 





e 解决 问题 的 重点 不 同 


打上 略 模 式 则 在 解决 内 部 算法 如 何 改变 的 问题 ， 也 就 是 将 内 部 算法 的 
改变 对 外 界 的 影响 降低 到 最 小 ， 它 保证 的 是 算法 可 以 自由 地 切换 ， 而 状 
态 模 式 旨 在 解决 内 在 状态 的 改变 而 引起 行为 改变 的 问题 ， 它 的 出 有 点 是 
事物 的 状态 ， 封 装 状 态 而 暴露 行为 ， 一 个 对 象 的 状态 改变 ， 从 外 界 来 看 
就 好 像 是 行为 改变 。 











e 解决 问题 的 方法 不 同 





策略 模式 只 是 确保 算法 可 以 自由 切换 ， 但 是 什么 时 候 用 什么 算法 它 
决定 不 了 ; 而 状态 模式 对 外 暴露 的 是 行为 ， 状 态 的 变化 一 般 是 由 环境 角 
色 和 具体 状态 共同 完成 的 ， 也 惑 是 说 状态 模式 封装 了 状态 的 变化 而 暴露 
了 不 同 的 行为 或 行为 结果 。 








e 应 用 场景 不 同 





两 者 都 能 实现 前 面 例子 中 的 场景 ， 但 并 不 表示 两 者 的 应 用 场景 相 
同 ， 这 只 是 为 了 更 好 地 展示 出 两 者 的 不 同 而 设计 的 一 个 场景 。 我 们 来 想 
一 下 策略 模式 和 状态 模式 的 使 用 场景 有 什么 不 同 ， 策 略 模式 只 是 一 个 算 
法 的 封装 ， 可 以 是 一 个 有 意义 的 对 象 ， 也 可 以 是 一 个 无 意义 的 逻辑 片 
段 ， 比 如 MD5 加 密 算 法 ， 它 是 一 个 有 意义 的 对 象 吗 ? 不 是 ， 它 只 是 我 们 
数学 上 的 一 个 公式 的 相关 实现 ， 它 是 一 个 算法 ， 同 时 DES 算 法 、RSA 算 
法 等 都 是 具体 的 算法 ， 也 就 是 说 它们 都 是 一 个 抽象 算法 的 具体 实现 类 ， 

















从 这 后 来 看 全 上 略 模 式 是 一 系列 平行 的 、 可 相互 蔡 换 的 算法 封装 后 的 结 

果 ， 这 就 限定 了 它 的 应 用 场景 : 算法 必须 是 平行 的 ， 否 则 朱 略 模式 束 圭 
闭 了 一 堆 坪 圾 ， 产 生 了 “ 坏 味道 "。 状 态 模式 则 要 求 有 一 系列 状态 发 生变 
化 的 场景 ， 它 要 求 的 是 有 状态 且 有 行为 的 场景 ， 也 就 是 一 个 对 象 必 须 具 
有 二 维 〈 状 态 和 行为 ) 描述 才能 采用 状态 模式 ， 如 果 只 有 状态 而 没有 行 
为 ， 则 状态 的 变化 残 失 去 了 意义 。 











e 复 末 度 不 同 


通常 策略 模式 比较 简单 ， 这 里 的 简单 指 的 是 结构 简单 ， 扩 展 比较 容 
易 ， 而 且 代 码 也 容易 阅读 。 当 然 ， 一 个 具体 的 算法 也 可 以 写 得 很 复杂 ， 
只 有 具备 很 高 深 的 数学 、 物 理 等 知识 的 人 才 可 以 看 屋 ， 这 也 是 允许 的 ， 
我 们 只 是 说 从 设计 模式 的 角度 来 分 机 ， 它 是 很 容易 被 看 懂 的 。 而 状态 模 
式 则 通常 比较 复杂 ， 因 为 它 要 从 两 个 角色 看 到 一 个 对 象 状态 和 行为 的 改 
变 ， 也 就 是 说 它 封装 的 是 变化 ， 要 知道 变化 是 无 穷尽 的 ， 因 此 相对 来 说 
状态 模式 通 第 部 比较 复 保 ， 涉 及 面 很 多 ， 虽 然 也 很 容易 扩展 ， 但 是 一 般 
不 会 进行 大 规模 的 扩张 和 修正 。 

















32.3 观察 者 模式 VS 责任 链 模 式 


为 什么 要 把 观察 者 模式 和 责任 链 模式 放 在 一 起 对 比 呢 ? 看 起 来 这 两 
个 模式 没有 太 多 的 相似 性 ， 真 没有 吗 ? 回答 是 有 。 我 们 在 观察 者 模式 中 
也 提 到 了 触发 链 《〈 也 叫做 观察 者 链 ) 的 问题 ， 一 个 有 具体 的 角色 既 可 以 是 
观察 者 ， 也 可 以 是 被 观察 者 ， 这 样 吏 形 成 了 一 个 观 峙 者 链 。 这 与 贡 任 链 
模式 非常 类 似 ， 它 们 都 实现 了 事务 的 链条 化 处 理 ， 比 如 说 在 上 诬 的 时 候 
你 睡 厦 了 ， 打 里 声 普 太 大 ， 盖 过 了 老师 讲 诬 声 普 ， 老 师 火 了 ， 捅 到 了 校 
长 这 里 ， 校 长 也 处 理 不 了 ， 然 后 告状 给 你 父母 ， 于 是 你 的 魔鬼 日 子 来临 
了 ， 这 是 责任 链 模式 ， 老 师 、 校 长 、 父 母 都 是 链 中 的 一 个 具体 角色 ， 事 
件 ( 你 睡觉 ) 在 链 中 传递 ， 最 终 由 一 个 具体 的 节点 来 处 理 ， 并 将 结果 反 
馈 给 调用 者 你 挨 捷 了 )〉 。 那 什么 是 触发 链 ? 你 还 是 在 读 符 上 睡觉， 还 
古 打 肢 声 首 太 大 ， 老 师 火 了 ， 但 是 老师 掏 出 个 扩 首 器 来 讲课 ， 于 是 你 睡 
不 着 了 ， 同 时 其 他 同学 的 耳 打 但 殖 了 ， 这 就 是 触及 链 ， 其 中 老师 既 古 观 
察 者 (相对 你 ) 也 是 被 观察 者 (相对 其 他 同学 ) ， 事 件 从 “你 睡觉 "到 老 
师 这 里 转化 为 “ 扩 音 右 放 大 声 首 ”"， 这 也 是 一 个 链条 结构 ， 但 是 链 结构 中 
传递 的 事件 改变 了 。 








我 们 还 是 以 一 个 具体 的 例子 来 说 明 两 者 的 区 别 ，DNS 协 议 相 信 大 家 
都 听 说 过 ， 只 要 在 “网 络 设置 ?中 设置 一 个 DNS 服务 器 地 址 就 可 以 把 我 们 
需要 的 域名 翻译 成 IP 地 址 。DNS 协 议 还 是 比较 简单 的 ， 传 递 过 去 一 个 域 


名 以 及 记录 标志 《比如 是 要 A 记 录 还 是 要 MX 记录 ) ，DNS 就 开始 查找 
自己 的 记录 树 ， 找 到 后 把 IP 地 址 反馈 给 请 求 者。 我 们 可 以 在 Windows 操 
作 系 统 中 了 解 一 下 DNS 解析 过 程 ， 在 DOS 窗 口 下 输入 nslookup 命 令 后 ， 
结果 如 图 32-6 所 示 。 


> WwWW IECOICD 
Server: 192.168.10.1 
Address: 192.168.10.1 


on_authoritative answer: 
XXX.XXECOI CH 
”202.108.33.122 


WAW EECOTD CD 





图 32-6 DNS 服务 器 解析 域名 


我 们 的 意图 就 是 要 DNS 服务 器 192.168.10.1 解 析出 www.xxx.com.cn 
的 IP 地 址 ，DNS 服 务 器 是 如 何 工作 的 呢 ? 图 32-6 中 的 192.168.10.1 这 个 
DNS Server 存 储 着 全 球 的 域名 和 IP 之 间 的 对 应 关系 吗 ? 不 可 能 ， 目 前 全 
球 的 域名 数量 是 1.7 亿 个 ， 如 此 庞大 的 数字 ， 每 个 DNS 服务 器 都 存储 一 
份 ， 还 怎么 快速 响应 ? DNS 解析 的 响应 时 间 一 般 都 是 毫秒 级 别 的 ， 如 此 


高 的 性 能 要 求 还 怎么 让 DNS 服务 器 通 地 开 人 花呢? 而 且 域 名 变更 非常 频 

每 ， 数 据 读 写 的 量 也 非常 大 ， 不 可 能 每 个 DNS 服务 器 都 保留 这 1.7 亿 数 

据 ， 那 么 是 怎么 设计 的 呢 ?”DNS 协 议 还 是 很 聪明 的 ， 它 规定 了 每 个 区 域 
的 DNS 服务 器 《Local DNS) 只 保留 目 己 区 域 的 域名 解析 ， 对 于 不 能 解 
析 的 域名 ， 则 提交 上 级 域名 解析 器 解析 ， 最 终 由 一 台 位 于 美国 洛杉矶 的 
顶级 域名 服务 器 进行 解析 ， 返 回 结 果 。 很 明显 这 是 一 个 事务 的 链 结构 处 
理 ， 我 们 使 用 两 种 模式 来 实现 该 解析 过 程 。 








32.3.1 员 任 链 模 式 实现 DNS 解 析 过 程 


本 小 节 我 们 用 责任 链 模式 来 实现 DNS 解 析 过 程 。 首 先 我 们 定义 一 下 
业务 场景 ， 这 里 有 三 个 DNS 服 务 器 : 上 海 DNS 服 务 器 (区 域 服务 器 )、 
中 国 顶级 DNS 服务 器 〈 父 服务 器 ) 、 全 球 顶 级 DNS 服务 器 ， 其 示意 图 如 


图 32-7 所 示 。 





上 海 DNS 中 国 顶 级 DNS 全 球 顶 级 DNS 





图 32-7 DNS 解析 示意 图 





假设 有 请 求 者 发 出 请 求 ， 由 上 海 DNS 进 行 解析 ， 如 果 能 够 解析 ， 则 
返回 结果 ， 知 不 能 解析 ， 则 提交 给 父 服 务 器 〈 中 国 项 级 DNS) 进行 解 


析 ， 若 还 不 能 解析 ， 则 提交 到 全 球 顶 级 DNS 进行 解析 ， 若 还 不 能 解析 
呢 ? 那 就 返回 该 域名 无 法 解析 。 确 实 ， 这 与 责任 链 模 式 非 常 相似， 我们 
把 这 一 过 程 抽 象 一 下 ， 类 图 如 图 32-8 所 示 。 


-DnsServer upperServer() 


+Recorder resolve(String domain) 
+setUpperServer(DnsServer upperServer) 
#D00lean isLocal(String domain) 
#Recorder echo(String domain) 











Recorder 


-String domain 





Client 2 
P| -String ip 


-String owner 





+getter/setter() 


图 32-8 贡 任 链 模 式 实现 DNS 解 析 的 类 图 


我 们 来 解释 一 下 类 图 ，Recorder 是 一 个 BO 对 象 ， 它 记录 DNS 服务 器 
解析 后 的 结果 ， 包 括 域名 、IP 地 址 、 属 主 ( 即 由 谁 解析 的 ) ， 除 此 之 外 
还 有 getter/setter 方 法 。DnsServer 抽 象 类 中 的 resolve 方 法 是 一 个 基本 方 
法 ， 每 个 DNS 服 务 器 都 必须 拥有 该 方法 ， 它 对 DNS 进 行 解析 ， 如 何 解 析 
呢 ? 具 体 是 由 echo 方 法 来 实现 的 ， 每 个 DNS 服 务 器 独自 实现 。 类 图 还 是 
比较 简单 的 ， 我 们 首先 看 一 下 解析 记录 Recorder 类 ， 如 代码 清单 32-31 所 


作 \。 


代码 清单 32-31 解析 记录 


public class Recorder { 


// 域 名 

private String domain; 

//IP 地 址 

private String ip; 

// 属 主 

private String owner; 

public String getDomain() { 
return domain; 





public void setDomain(String domain) { 
this.domain = domain; 


} 
public String getIp() { 
return ip; 


} 
public void setIp(String ip) { 
this.ip = ip; 


public String getOwner() { 
return owner; 


public void setOwner(String owner) { 
this.owner = owner,; 


} 
// 输 出 记录 信息 
Q@Override 
public String toString(){ 
String str= "域名 : " + this.domain， 
str = str + "NnIP 地 址 : " + this.ip; 
str = str + "Nn 解 析 者 : " + this.owner; 
return str; 

















为 什么 要 履 写 toString 方 法 呢 ? 是 为 了 打印 展示 的 需要 ， 可 以 直接 


把 Recorder 的 信息 打印 出 来 。 我 们 再 来 看 抽象 域名 服务 器 ， 如 代码 清单 
32-32 上 所 示 。 


代码 清单 32-32 抽象 域名 服务 器 


public abstract class DnsServer { 


// 上 级 DNS 是 谁 





private DnsServer UpperServer ; 
// 解 析 域 名 
public final Recorder resolve(String domain)t{ 
Recorder recorder=null; 
if(isLocal(domain)){// 是 本 服务 器 能 解析 的 域名 
recorder = echo(domain); 
}else{// 本 服务 器 不 能 解析 
// 提 交 上 级 DNS 进 行 解析 
recorder = upperServer.resolve(domain); 








} 
return recorder; 

} 

// 指 向 上 级 DNS 

public void setUpperServer(DnsServer _upperServer)t 
this.upperServer = _upperServer; 

















} 
// 每 个 DNS 都 有 一 个 数据 处 理 区 (ZONE) ,检查 域名 是 否 在 本 区 中 
protected abstract boolean isLocal(String domain); 
// 每 个 DNS 服务 器 都 必须 实现 解析 任务 
protected Recorder echo(String domain){ 
Recorder recorder = new Recorder(); 
// 获 得 IP 地 址 
recorder.setIip(genIipAddress( )); 
recorder.setDomain(domain); 
return recorder; 




















} 

// 随 机 产生 一 个 IP 地 址 ， 工 具 类 

private String genIpAddress(){ 
Random rand = new Random( ) ; 
String address = rand,nextInt(255) + "." + rand.next 
return address 





在 该 类 中 有 一 个 方法 一 一 genIpAddress 方 法 一 一 没有 在 类 图 中 展现 
出 来 ， 它 用 于 实现 随机 生成 IP 地 址 ， 这 是 我 们 为 模拟 DNS 解 析 场 景 而 建 
立 的 一 个 虚拟 方法 ， 在 实际 的 应 用 中 是 不 可 能 出 现 的。 抽象 DNS 服 务 器 
编写 完成 ， 我 们 再 来 看 具体 的 DNS 服 务 器 ， 先 看 上 海 的 DNS 服 务 器 ， 如 
代码 清单 32-33 所 示 。 





代码 清单 32-33 上 海 DNS 服 务 器 


public class SHDnsServer extends DnsServer { 
@Override 
protected Recorder echo(String domain) { 
Recorder recorder= super.echo(domain); 
recorder .setOwner ("上 海 DNS 服 务 器 ")， 
return recorder; 


} 

// 定 义 上 海 的 DNS 服务 器 能 处 理 的 级 别 

@Override 

protected boolean isLocal(String domain) { 
return domain.endsWith(".sh.cn"); 

} 























为 什么 要 履 写 echo 方 法 ? 各 具体 的 DNS 服务 器 实现 自己 的 解析 过 
程 ， 属 于 个 性 化 处 理 ， 它 代表 的 是 每 个 DNS 服 务 器 的 不 同 处 理 逻 辑 。 还 
要 注意 一 下 ， 我 们 在 这 里 做 了 一 个 简化 处 理 ， 所 有 以 ".sh.cn" 结 尾 的 域名 
都 由 上 海 DNS 服 务 器 解析 。 其 他 的 中 国 项 级 DNS 和 全 球 顶 级 DNS 实 现 过 
程 类 似 ， 如 代码 清单 32-34、32-35 所 示 。 


代码 清单 32-34 中 国 顶 级 DNS 服 务 右 


public class ChinaTopDnsServer extends DnsServer { 
@Override 
protected Recorder echo(String domain) { 
Recorder recorder = super.echo(domain); 
recorder .setOwner ("中国 顶级 DNS 服 务 器 "); 
return recorder; 


Q@override 

protected boolean isLocal(String domain) { 
return domain.endsWith(".cn"); 

} 


代码 清单 32-35 全 球 顶 级 DNS 服务 器 


public class TopDnsServer extends DnsServer { 
@Override 
protected Recorder echo(String domain) { 
Recorder recorder = super.echo(domain); 
recorder .setOwner ("全 球 顶 级 DNS 服 务 器 ")，; 
return recorder; 


@Override 
protected boolean isLocal(String domain) { 
// 所 有 的 域名 最 终 的 解析 地 点 


return true; 











所 有 的 DNS 服务 器 都 准备 好 了 ， 下 面 我 们 写 一 个 客户 端 来 模拟 一 下 
IP 地 址 是 怎么 解析 的 ， 如 代码 清单 32-36 所 示 。 


代码 清单 32-36 场景 类 


public class Client { 
public static void main(String[] args) throws Exception { 
// 上 海域 名 服务 器 
DnsServer sh = new SHDnsServer(); 
// 中 国 顶级 域名 服务 器 
DnsServer china = new ChinaTopDnsServer(); 


// 全 球 顶 级 域名 服务 器 
DnsServer top = new TopDnsServer(); 
// 定 义 查 询 路 径 





china.setUpperServer(top); 
sh.setUpperServer(china); 
// 解 析 域 名 
System.out .printlin("===== 域 名 解析 模拟 器 =====" ); 
while(true)t 
System,out.print("Nn 请 输入 域名 (输入 N 退 出 ) :7")， 
String domain = (new BufferedReader(new Inpu 
if(domain.equalsIgnoreCase("n"))t{ 
return; 
} 


Recorder recorder = sh.resolve(domain); 
System.out.println("----DNS 服 务 器 解析 结果 ----" 








System.out ,println(recorder ) ; 


我 们 来 模拟 一 下 ， 运 行 结果 如 下 所 示 : 

















请 输入 域名 (输入 N 退 出 ):www.xxx.sh.cn 





----DNS 服 务 器 解析 结果 ---- 





域名 : www. xxx.sh.cn 
IP 地 址 : 69.224.162.154 


解析 者 : 上 海 DNS 服 务 器 

















请 输入 域名 (输入 N 退 出 ):www. xxx.com.cn 





----DNS 服 务 器 解析 结果 ---- 





域名 : www. xxx.com.cn 
IP 地 址 : 51.28.66.140 


解析 者 : 中 国 顶级 DNS 服 务 器 





请 输入 域名 (输入 N 退 出 ):www. xxx.com 





----DNS 服 务 器 解析 结果 ---- 





域名 : www. xxXX.com 
IP 地 址 : 73.247.80.117 


解析 者 : 全 球 顶 级 DNS 服务 器 

















请 输入 域名 (输入 N 退 出 ):n 





请 注意 看 运行 结果 ， 以 ".sh.cn" 结 尾 的 域名 确实 由 上 海 DNS 服 务 器 解 


析 了 ， 以 ".cn" 结 尾 的 域名 由 中 国 顶级 DNS 服务 器 解析 了 ， 其 他 域名 都 由 
全 球 顶 级 DNS 服务 需 解 林 。 这 个 异 拟 过 程 看 起 来 很 完整 ， 它 完全 残 是 贡 
任 链 模 式 的 一 个 具体 应 用 ， 把 一 个 请 求 放置 到 链 中 的 首 市 皮 ， 然 后 由 链 
中 的 东 个 节点 进行 解析 并 将 结果 反馈 给 调用 者 。 但 是 ， 我 可 以 负责 任 地 
告诉 你 : 这 个 解析 过 程 证 有 缺陷 的 ， 什 么 缺陷 ? 后 面 会 说 明 。 





32.3.2 触发 链 模 式 实 现 DNS 解 析 过 程 


上 面 说 到 使 用 责任 链 模 式 模 拟 DNS 解析 过 程 是 有 缺陷 的 ， 究 竟 有 什 
么 缺陷 ? 大 家 是 不 是 觉得 这 个 解析 过 程 很 完美 了 ， 没 什么 问题 了 ? 那 说 
明 你 对 DNS 协议 了 解 得 还 不 太 深 入 。 我 们 来 做 一 个 实验 ， 在 dos 窗 口 下 
输入 nslookup 命 令 ， 然 后 输入 多 个 域名 ， 注 意 观 察 返 回 值 有 哪些 数据 是 
相同 的 。 可 以 看 出 ， 解 析 者 都 相同 ， 都 是 由 同一 个 DNS 服务 需 解 析 的 ， 
准确 地 说 都 是 由 本 机 配置 的 DNS 服务 器 做 的 解析 。 这 与 我 们 上 面 的 模拟 
过 程 是 不 相同 的 ， 看 看 我 们 模拟 的 过 程 ， 对 请 求 者 来 说 ，".sh.cn" 是 由 区 
域 DNS 解析 的 ，".com" 却 是 由 全 球 顶 级 DNS 解析 的 ， 与 真实 的 过 程 不 相 


同 ， 这 是 怎么 回 事 呢 ? 




















肯定 地 说 ， 采 用 责任 链 模 式 模拟 DNS 解 析 过 程 是 不 完美 的 ， 或 者 说 
是 有 缺陷 的 ， 怎 么 来 修复 这 个 缺陷 呢 ? 我 们 先 来 看 看 真实 的 DNS 解 析 过 
程 ， 如 图 32-9 所 示 。 








图 32-9 真实 的 DNS 解析 示意 图 


解析 一 个 域名 的 完整 路 径 如 图 32-9 中 的 标号 中 一 @ 所 示 ， 首 先 由 请 
求 者 发 送 一 个 请 求 ， 然 后 由 上 海 DNS 服 务 器 尝试 解析 ， 若 不 能 解析 再 通 
过 路 径 @@ 转 发 给 中 国 顶级 DNS 进 行 解析 ， 人 解析 后 的 结果 通过 路 径 加 返回 
给 上 海 DNS 服 务 器 ， 然 后 由 上 海 DNS 服 务 器 通过 路 径 @ 返 回 给 请 求 者 。 
同样 ， 若 中 国 顶级 DNS 不 能 解析 ， 则 通过 路 径 G3) 转 由 全 球 项 级 DNS 进行 
解析 ， 通 过 路 径 则 把 结果 返回 给 中 国 顶级 DNS， 然 后 再 通过 路 径 加 返回 
给 上 海 DNS。 注 音 看 标号 @)， 不 管 一 个 域名 最 终 由 谁 解析 ， 最 终 反 馈 到 
请 求 者 的 还 是 第 一 个 节点 ， 也 束 是 说 首 节点 负责 对 请 求 者 应 答 ， 其 他 
点 都 不 与 请 求 者 交互 ， 而 只 与 目 己 的 左右 节点 交互 。 实 际 上 我 们 的 DNS 
服务 堪 人 确实 是 如 此 处 理 的 ， 例 如 本 机 请 求 得 询 一 个 www.abcdefg.com 的 
域名 ， 上 海 DNS 服 务 器 解析 不 到 这 个 域名 ， 于 是 提交 到 中 国 顶 级 DNS 服 
务 器 ， 如 果 中 国 顶 级 DNS 服 务 器 有 该 域名 的 记录 ， 则 找到 该 记录 ， 反 人 馈 
到 上 海 DNS 服务 器 ， 上 海 DNS 服务 器 做 两 件 事务 处 理 : 一 是 啊 应 请 求 
者 ， 二 是 存储 该 记录 ， 以 备 其 他 请 求 者 再 次 查询 ， 这 类 似 于 数据 缓存 。 
































整个 场景 我 们 已 经 清晰 ， 想 想 看 ， 我 们 把 请 求 者 看 成 是 被 观察 者 ， 
它 的 行为 或 属性 变更 通知 了 观察 者 一 一 上 海 DNS， 上 海 DNS 叉 作为 被 观 





穴 者 出 现 了 目 己 不 能 处 理 的 行为 “行为 改变 ) ， 通 知 了 中 国 顶级 DNS， 
依次 类 推 ， 这 是 不 是 一 个 非常 标准 的 触发 链 ? 而 且 还 必须 是 同步 的 触 
>， 异步 触发 已 经 在 该 场景 中 失去 了 意义 (读者 可 以 想 想 为 什么 〉。 








分 析 了 这 么 多 ， 我 们 用 触 友 链 来 模拟 DNS 的 解析 过 程 ， 如 图 32-10 
所 示 。 













java.util.Observable <<interface>> 
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EE 人 === 到 
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+update(Observable arg0, Object arg1) -Strng domam 
+void setUpperServer(DnsServer dnsServer) -Strmg Pp 


= -== 
| #yoid sign(Recorder recorder) -Strng owner 
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TopDnsServer 





图 32-10 触发 链 模 式 实现 DNS 解 析 的 类 图 


与 责任 链 模 式 很 相似 ， 仅 仅 多 了 一 个 Observable 父 类 和 Observer 接 
口 ， 但 是 在 实现 上 这 两 种 模式 有 非常 大 的 差异 。 我 们 先 来 解释 一 下 抽象 
DnsServer 的 作用 。 








e 标示 声明 


表示 所 有 的 DNS 服务 器 都 具备 双重 身份 : 既是 观察 者 也 是 被 观察 
者 ， 这 很 重要 ， 它 声明 所 有 的 服务 器 都 具有 相同 的 号 份 标志 ， 有 具有 该 标 
志 后 就 可 以 在 链 中 随意 移动 ， 而 无 需 固 定 在 链 中 的 茶 个 位 置 《〈 这 也 是 链 
的 二 个 生 要 特性 姓 : 








e 业务 抽象 


方法 setUpperServer 的 作用 是 设置 父 DNS， 也 就 是 设置 自己 的 观 罕 
者 ，update 方 法 不 仅仅 是 一 个 事件 的 处 理 者 ， 也 同时 是 事件 的 触发 者 。 


我 们 来 看 代码 ， 首 先是 最 简单 的 ，Recorder 类 与 责任 链 模 式 中 的 记 
录 相 同 ， 这 里 不 再 袭 述 。 那 我 们 就 先 看 看 该 模式 的 核心 抽象 
DnsServer， 如 代码 清单 32-37 所 示 。 


代码 清单 32-37 抽象 DNS 服 务 右 


public abstract class DnsServer extends Observable implements Obs 
// 处 理 请 求 ， 也 就 是 接收 到 事件 后 的 处 理 
public void update(Observable arg0, Object arg1) { 
Recorder recorder = (Recorder)argi; 
// 如 果 本 机 能 解析 
if(isLocal(recorder))t 
recorder.setIip(genIipAddress()); 
}else{// 本 机 不 能 解析 ， 则 提交 到 上 级 DNS 
responsFromUpperServer(recorder); 















































} 
// 签 名 
sign(recorder); 


} 

// 作 为 被 观察 者 ， 人 允许 增加 观察 者 ， 这 里 上 级 DNS 一 般 只 有 一 个 

public void setUpperServer(DnsServer dnsServer)t{ 
// 先 清空 ， 然 后 再 增加 
super.deleteObservers(); 
Super ,addobserver(dnsServer ) ， 











} 
// 辐 父 DNS 请 求解 析 ， 也 就 是 通知 观察 者 
private void responsFromUpperServer(Recorder recorder)t{ 
super.setChanged( ); 
super .notifyObservers(recorder); 


} 

// 每 个 DNS 服务 器 签 上 自己 的 名 字 

protected abstract void sign(Recorder recorder); 

// 每 个 DNS 服务 器 都 必须 定义 自己 的 处 理 级 别 

protected abstract boolean isLocal(Recorder recorder ) ; 

// 随 机 产生 一 个 IP 地 址 ， 工 具 类 

private String genIpAddress(){ 
Random rand = new Random( ) ; 
String address = rand.nextInt(255) + "." + rand.next 
return address,; 





























注意 看 一 下 responseFromUpperServer 方 法 ， 它 只 允许 设置 一 个 观察 
者 ， 因 为 一 般 的 DNS 服 务 嚣 都 只 有 一 个 上 级 DNS 服 务 器 。sign 方 法 是 签 
名 ， 这 个 记录 是 由 谁 解 析出 来 的 ， 就 由 各 个 实现 类 独自 来 实现 。 三 个 
DnsServer 的 实现 类 都 比较 简单 ， 如 代码 清单 32-38、32-39、32-40 所 











钞 。 


代码 清单 32-38 上 海 DNS 服 务 器 


public class SHDnSsServer extends DnsServer { 
@Override 
protected void sign(Recorder recorder) { 
recorder .setOwner ("上 海 DNS 服 务 器 ")， 


} 
// 定 义 上 海 的 DNS 服务 器 能 处 理 的 级 别 
@Override 
protected boolean isLocal(Recorder recorder) { 
return recorder.getDomain().endswith(".sh.cn"); 
} 




















代码 清单 32-39 中 国 顶 级 DNS 服 务 右 


public class ChinaTopDnsServer extends DnsServer { 
@Override 
protected void sign(Recorder recorder) { 
recorder .setOwner ("中 国 顶级 DNS 服 务 器 " ) ， 


@Override 

protected boolean isLocal(Recorder recorder) { 
return recorder.getDomain().endswWith(".cn"); 

} 


代码 清单 32-40 全 球 顶 级 DNS 服 务 器 


public class TopDnsServer extends DnsServer { 
@Override 
protected void sign(Recorder recorder) { 
recorder .setOwner ("全 球 顶级 DNS 服 务 器 " ) ， 
} 


@Override 
protected boolean isLocal(Recorder recorder) { 
// 所 有 的 域名 最 终 的 解析 地 点 


return true; 








我 们 再 建立 一 个 场景 类 模拟 一 下 DNS 解 析 过 程 ， 如 代码 清单 32-41 
所 示 。 


代码 清单 32-41 场景 类 


public class Client { 
public static void main(String[] args) throws Exception { 

// 上 海域 名 服务 器 
DnsServer sh = new SHDnsServer(); 
// 中 国 顶级 域名 服务 器 
DnsServer china = new ChinaTopDnsServer(); 
// 全 球 顶 级 域名 服务 器 
DnsServer top = new TopDnsServer(); 
// 定 义 查 询 路 径 
china.setUpperServer(top); 





sh,.SetUpperServer(china) ; 

// 解 析 域 名 

System.out,printJn("===== 域 名 解析 模拟 器 =====" ) ; 

while(true){ 
System,out.print("Nn 请 输入 域名 (输入 N 退 出 ) :7")， 
String domain = (new BufferedReader(new Inpu 
if(domain.equalsIgnoreCase("n"))t{ 

return; 





Recorder recorder = new Recorder(); 
recorder.setDomain(domain); 
sh.update(null,recorder); 

System.out .println("----DNS 服 务 器 解析 结果 ----" 
System.out.println(recorder); 








与 责任 链 模 式 中 的 场景 类 很 相似 。 读 者 请 注意 
sh.update(null,recorder) 这 人 句 代码 ， 这 是 我 们 虚拟 了 观察 者 触发 动作 ， 
整 的 做 法 是 把 场景 类 作为 一 个 被 观察 者 ， 然 后 设置 观察 者 为 上 海 DNS 服 
务 器 ， 再 进行 测试 ， 其 结果 完全 相同 ， 我 们 这 里 为 减少 代码 量 采用 了 简 
化 处 理 ， 有 兴趣 的 读者 可 以 扩充 实现 。 


我 们 来 看 看 运行 结果 如 何 ， 结 果 如 下 所 示 : 

















请 输入 域名 (输入 N 退 出 ):www.xxx.sh.cn 





----DNS 服 务 器 解析 结果 ---- 





域名 : www.xxx.sh.cn 
IP 地 址 : 197.15.34.227 


解析 者 : 上 海 DNS 服 务 器 

















请 输入 域名 (输入 N 退 出 ):www.xxx.com.cn 





----DNS 服 务 器 解析 结果 ---- 





域名 : www.xxx.com.cn 
IP 地 址 : 201.177.148.99 


解析 者 : 上 海 DNS 服 务 器 

















请 输入 域名 (输入 N 退 出 ):www.xxx.com 





----DNS 服 务 器 解析 结果 ---- 





域名 : www.xxx.com 
IP 地 址 : 251.41.14.230 


解析 者 : 上 海 DNS 服 务 器 

















请 输入 域名 (输入 N 退 出 ):n 

可 以 看 出 ， 所 有 的 解析 结果 都 是 由 上 海 DNS 服 务 需 返回 的 ， 这 才 是 
真正 的 DNS 解析 过 程 。 如 何 知道 它 是 由 上 海 DNS 服 务 器 解析 的 还 是 由 别 
的 DNS 服务 器 解析 的 呢 ? 很 好 办 ， 把 代码 拷贝 过 去 ， 然 后 调试 跟 踩 一 下 
就 可 以 了 。 或 者 仔细 看 看 代码 ， 理 解 一 下 代码 逻辑 也 可 以 非常 清楚 地 知 
道 它 是 如 何 解析 的 。 


再 仔细 看 一 下 我 们 的 代码 逻辑 ， 上 下 两 个 节点 之 间 的 关系 很 微妙 ， 
很 有 意思 。 


e 下 级 节点 对 上 级 节点 顶礼 膜拜 


比如 我 们 输入 的 这 个 域名 www.xxx.com， 上 海域 名 服务 器 只 知道 它 


是 由 父 节点 《中 国 顶级 DNS 服务 器 ) 解析 的 ， 而 不 知道 父 节 点 把 该 请 求 
转发 给 了 更 上 层 节点 〈 全 球 项 级 DNS 服务 器 ) ， 也 就 是 说 下 级 节点 关注 
的 是 上 级 节点 的 响应 ， 只 要 是 上 级 反馈 的 结果 就 认为 是 上 级 的 。 
www.XXX.com 这 个 域名 最 终 是 由 最 高 节点 《全 球 顶 级 DNS 服务 器 ) 解析 
的 ， 它 把 解析 结果 传递 给 第 二 个 节点 〈 中 国 顶 级 DNS 服务 器 ) 时 的 签名 
为 “全 球 顶 级 DNS 服 务 器 *"， 而 第 二 个 节点 把 请 求 传 递 给 首 节 点 (上海 
DNS 服务 器 ) 时 的 签名 被 修改 为 "中国 顶级 DNS 服务 器 ?。 上 所 有 从 上 级 节 
点 反馈 的 响应 都 认为 是 上 级 节点 处 理 的 结果 ， 而 不 追究 到 底 是 不 是 真 的 
是 上 级 节点 处 理 的 。 























e 上 级 布点 对 下 级 节点 绝对 信任 


上 级 节点 只 对 下 级 节点 负责 ， 它 不 关心 下 级 贡 点 的 请 求 从 何 而 来 ， 
只 要 是 下 级 发 送 的 请 求 就 认为 是 下 级 的 。 还 是 以 www.xxx.com 域 名 为 
例 ， 当 最 高 节点 《全 球 项 级 DNS 服务 器 ) 获得 解析 请 求 时 ， 它 认为 这 个 
请 求 是 谁 的 ? 当然 是 第 二 个 节点 《中国 顶级 DNS 服务 器 ) 的 ， 人 否则 它 也 
不 会 把 结 末 反馈 给 它 ， 但 是 这 个 请 求 的 源头 却 是 首 节 点 “上海 DNS 服务 
器 ) 的 。 





3233.3 小 车 


通过 对 DNS 解析 过 程 的 实现 ， 我 们 发 现 触 发 链 和 责任 链 虽 然 都 是 链 





结构 ， 但 是 还 是 有 区 别 的 。 


e 链 中 的 消 轧 对 象 不 同 





从 首 节 点 开始 到 最 终 的 尾 节 点 ， 两 个 链 中 传递 的 消 恩 对 象 是 不 同 
的 。 责 任 链 模式 基本 上 不 改变 消息 对 象 的 结构 ， 虽 然 每 个 节点 都 可 以 参 
与 消费 〈 一 般 是 不 参与 消费 ) ， 类 似 于 “ 雁 过 拔 毛 ?”， 但 是 它 的 结构 不 会 
改变 ， 比 如 从 首 节 点 传递 进来 一 个 String 对 象 或 者 Person 对 象 ， 不 会 到 链 
尾 的 时 候 成 了 int 对 象 或 者 Human 对 象 ， 这 在 责任 链 模 式 中 是 不 可 能 的 ， 
但 是 在 触发 链 模式 中 是 允许 的 ， 链 中 传递 的 对 象 可 以 目 由 变化 ， 只 要 上 
下 级 节点 对 传递 对 象 了 解 即 可 ， 它 不 要 求 链 中 的 消 居 对 象 不 变化 ， 它 只 
要 求 链 中 相 邻 两 个 节点 的 消 明 对 象 固定 。 











e 上 下 市 点 的 关系 不 同 


在 贡 任 链 模式 中 ， 上 下 市 点 没有 关系 ， 部 是 接收 同样 的 对 象 ， 所 有 
传递 的 对 象 都 是 从 链 首 传递 过 来 ， 上 一 节点 是 什么 没有 关系 ， 只 要 按照 
目 己 的 逻辑 处 理 束 成 。 而 触发 链 模 式 束 不 同 了 ， 它 的 上 下 级 关系 很 亲 
密 ， 下 级 对 上 级 顶礼 膜拜 ， 上 级 对 下 级 绝对 信任 ， 链 中 的 任意 两 个 相 邻 
节点 都 是 一 个 牢固 的 独立 团体 。 


e 消息 的 分 销 渠 道 不 同 


在 贡 任 链 模式 中 ， 一 个 消息 从 链 首 传递 进来 后 ， 束 开始 沿 着 链条 癌 





链 尾 运 动 ， 方 向 是 单一 的 、 固 定 的 ; 而 触发 链 模式 则 不 同 ， 由 于 它 采 用 
的 是 观察 者 模式 ， 所 以 有 非常 大 的 灵活 性 ， 一 个 消息 传递 到 链 首 后 ， 具 
体 怎 么 传递 是 不 固定 的 ， 可 以 以 广播 方式 传递 ， 也 可 以 以 跳跃 方式 传 
递 ， 这 取决 于 处 理 消息 的 逻辑 。 





第 33 章 ” 跨 战 区 PK 


创建 类 模式 描述 如 何 创建 对 象 ， 行 为 类 模式 关注 如 何 管理 对 象 的 行 
为 ， 结 构 类 模式 则 着 重 于 如 何 建立 一 个 软件 结构 ， 虽 然 三 种 模式 的 着 重 
扩 不 同 ， 但 是 在 实际 应 用 中 还 是 有 和 草 县 的 ， 会 出 现 一 种 模式 适用 、 男 外 
一 种 模式 也 适用 的 情况 ， 我 们 到 请 该 选用 哪 一 个 设计 模式 呢 ? 本 章 就 这 
领 读者 进入 不 同类 设计 模式 PK 的 世界 中 ， 让 你 清晰 地 认识 到 各 个 模式 
的 不 同 点 以 及 它们 的 特长 。 














33.1 策略 模式 VS 桥梁 模式 


这 对 冤家 终于 页 涉 了 ， 策 略 模 式 与 桥梁 模式 是 如 此 相似 ， 简 直 束 是 
挛 生 兄弟 ， 要 把 它们 两 个 分 开 可 不 太 容 易 。 我 们 来 看 看 两 者 的 通用 类 
图 ， 如 图 33-1 所 示 。 
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图 33-1 策略 模式 《〈 左 ) 和 桥梁 模式 〈 右 ) 通用 类 图 


两 者 之 间 确 实 很 相似 。 如 果 把 策略 模式 的 环境 角色 变更 为 一 个 抽象 
类 加 一 个 实现 类 ， 或 者 桥梁 模式 的 抽象 角色 未 实现 ， 只 有 修正 抽象 化 角 
色 ， 想 想 看 ， 这 两 个 类 图 有 什么 地 方 不 一 样 ? 完全 一 样 ! 正 是 由 于 类 似 
场景 的 存在 才 导 致 了 两 者 在 实际 应 用 中 经 利 混 消 的 情况 发 生 ， 我 们 来 举 
例 说 明 两 者 有 何 差别 。 








大 家 都 知道 邮件 有 两 种 格式 : 文本 邮件 (Text Mail) 和 超 文 本 邮件 
(HTML MaiL ) ,在 文本 邮件 中 只 能 有 简单 的 文字 信息 ， 而 在 超 文 本 邮 
件 中 可 以 有 复杂 文字 《〈 带 有 颜色 、 字 体 等 属性 ) 、 图 片 、 视 频 等 ， 如 果 
你 使 用 Foxmail 邮 件 客户 端的 话 就 应 该 有 深刻 体验 ， 看 到 一 份 邮 件 ， 怎 











么 没 内 容 ? 原来 是 你 忘记 点 击 那个 "HTML 邮 件 ” 标 签 了 。 下 面 我 们 就 来 
讲解 如 何 发 送 这 两 种 不 同 格式 的 邮件 ， 研 究 一 下 这 两 种 模式 如 何 处理 这 
样 的 场景 。 


33.1.1 策略 模式 实现 邮件 及 送 


使 用 策略 模式 发 送 邮件 ， 我 们 认为 这 两 种 邮件 是 两 种 不 同 的 封装 格 
式 ， 给 定 了 发 件 人 、 收 件 人 、 标 题 、 内 容 的 一 封 邮件 ， 按 照 两 种 不 同 的 
格式 分 别 进行 封装 ， 然 后 发 送 之 。 按 照 这 样 的 分 析 ， 我 们 发 现 邮 件 的 两 
种 不 同 封装 格式 就 是 两 种 不 同 的 算法 ， 有 具体 到 策略 模式 就 是 两 种 不 同 策 
略 ， 这 样 看 已 经 很 简单 了 ， 我 们 可 以 直接 套用 策略 模式 来 实现 。 先 看 类 
图 ， 如 图 33-2 所 示 。 
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重 写 getContext 方 法 、 





图 33-2 策略 模式 实现 邮件 发 送 的 类 图 


我 们 定义 了 一 个 邮件 模板 ， 它 有 两 个 实现 类 : TextMail (文本 邮 
件 ) 和 HtmlMail ( 超 文 本 邮件 ) ， 分 别 实 现 两 种 不 同 格 式 的 邮件 封闭。 
MailServer 是 一 个 环境 角色 ， 它 接收 一 个 MailTemplate 对 象 ， 然 后 通过 
sendMail 方 法 发 送出 去 。 我 们 来 看 具体 的 代码 ， 先 看 抽象 邮件 ， 如 代码 


清单 33-1 所 示 O 〇 


代码 清单 33-1 抽象 邮件 


public abstract class MailTemplate { 
// 邮 件 发 件 人 
private String from; 
// 收 件 人 
private String to; 
// 邮 件 标题 
private String subject; 


// 邮 件 内 容 
private String context; 


// 通 过 构造 函数 传递 邮件 信息 


lk 





public MailTemplate(String _from,String _to,String _subject, 


this.from = _from; 
this.to = _to; 

this. subject 
this.context 


= _subject; 
= _context; 
public String getFrom() { 

return from; 


public void setFrom(String from) { 
this.from = from; 


} 
public String getTo() { 
return to; 


public void setTo(String to) { 
this.to = to; 


public String getSubject() { 
return subject,; 


} 
public void setSubject(String subject) { 
this.subject = subject; 


public void setContext(String context)t{ 
this.context = context; 


} 

// 邮 件 都 有 内 容 

public String getContext(){ 
return context; 

2 








很 奇怪 ， 是 吗 ? 抽象 类 没有 抽象 的 方法 ， 设 置 为 抽象 类 还 有 什么 意 


义 昵 ?有 意义 ， 在 这 里 我 们 定义 了 一 个 这 样 的 抽象 类 


: 它 具 有 邮件 的 所 


有 属性 ， 但 不 是 一 个 具体 可 以 被 实例 化 的 对 象 。 例 如 ， 你 对 邮件 服务 器 


说 “给 我 制造 一 封 邮 件 ”， 邮件 服务 器 肯定 拒绝 ， 为 什么 


? 你 要 产生 什么 


邮件 ? 什么 格式 的 ?邮件 对 邮件 服务 器 来 说 是 一 个 抽象 表示 ， 是 一 个 可 


描述 但 不 可 形象 化 的 事物 。 你 可 以 这 样 说 :“ 我 要 一 封 标题 为 XX， 发 件 
人 是 XXX 的 文本 格式 的 邮件 >， 这 就 是 一 个 可 实例 化 的 对 象 ， 因 此 我 们 
的 设计 就 产生 了 两 个 子 类 以 具体 化 邮件 ， 而 且 每 种 邮件 格式 对 邮件 的 内 
容 都 有 不 同 的 处 理 。 我 们 首先 看 文本 邮件 ， 如 代码 清单 33-2 所 示 。 


代码 清单 33-2 文本 邮件 


public class TextMail extends MailTemplate { 
public TextMail(String _from, String _to, String _subject, S 
super(_from, _to, _subject, _context); 


} 
public String getContext() { 
// 文 本 类 型 设置 邮件 的 格式 为 : text/plain 
String context = "\nContent- 2 text/plain;charset 
// 同 时 对 邮件 进行 Dase64 编 码 处 理 , 这 一 句 话 代替 
context = context + ee 文本 格式 "， 
return context; 























我 们 用 写 了 getContext 方 法 ， 因 为 要 把 一 封 邮件 设置 为 文本 邮件 必 
须 加 上 一 个 特殊 的 标志 : text/plain， 用 于 告诉 解析 这 份 邮件 的 客户 
端 : “我 是 一 封 文本 格式 的 邮件 ， 别 解析 错 了 ”。 同 样 ， 超 文本 格式 的 邮 
件 也 有 类 似 的 设置 ， 如 代码 清单 33-3 所 示 。 


代码 清单 33-3 超 文 本 邮件 


public class HtmlMail extends MailTemplate f{ 
public HtmlMail(String _from, String _to, String _subject, S 
super(_from, _to, _subject, _context); 


} 
public String getContext()t{ 
// 超 文本 类 型 设置 邮件 的 格式 为 : multipart/mixed 
String context = "\nContent-Type: multipart/mixed; c 


// 同 时 对 邮件 进行 HTML 检 查 ， 是 否 有 类 似 未 关闭 的 标签 





context = context + "xn 邮件 格式 为 : 超 文本 格式 "， 
return context 


优秀 一 点 的 邮件 客户 端 会 对 邮件 的 格式 进行 检查 ， 比 如 编写 一 封 超 
文本 格式 的 邮件 ， 在 内 容 中 加 上 了 <font> 标 签 ， 但 是 遗忘 了 </font> 结 尾 
标签 ， 邮 件 的 产生 者 《也 就 是 邮件 的 客户 端 ) 会 提示 进行 修正 ， 我 们 这 
里 用 了 “邮件 格式 为 : 超 文 本 格式 ”来 代表 该 逻辑 。 


两 个 实现 类 实现 了 不 同 的 算法 ， 给 定 相 同 的 发 件 人 、 收 件 人 、 标 题 
和 内 容 可 以 产生 不 同 的 邮件 信息 。 我 们 看 看 邮件 是 如 何 发 送出 去 的 ， 如 
代码 清单 33-4 所 示 。 


代码 清单 33-4 邮件 服务 器 


public class MailServer { 
// 发 送 的 是 哪 封 邮件 
private MailTemplate m; 
public MailServer(MailTemplate _m){ 
this.m = _m; 


} 

// 发 送 邮 件 

public void sendMail( ){ 
System.out.println("==== 正 在 发 送 的 邮件 信息 ====" )， 
// 发 件 人 
System,out.println(" 发 件 人 : " + m.getFrom()); 
// 收 件 人 
System.out.println(" 收 件 人 : " + m.getTo()); 
// 标 题 
System,out,println(" 邮 件 标题 : " + m.getSubject()); 
// 邮 件 内 容 
System.out.println(" 邮 件 内 容 : " + m.getcontext()); 





很 简单 ， 邮 件 服务 器 接收 了 一 封 邮 件 ， 然 后 调用 自己 的 发 送 程序 进 
行 发 送 。 可 能 读者 要 问 了 ， 为 什么 不 把 sendMail 方 法 移植 到 邮件 模板 类 
中 呢 ? 这 也 是 邮件 模板 类 的 一 个 行为 ， 邮 件 可 以 被 发 送 。 是 的 ， 这 确实 
是 邮件 的 一 个 行为 ， 完 全 可 以 这 样 做 ， 两 者 没有 什么 区 别 ， 只 是 从 不 同 
的 角度 看 待 该 方法 而 已 。 我 们 继续 看 场景 类 ， 如 代码 清单 33-5 所 示 。 





代码 清单 33-5 场景 类 


public class Client { 
public static void main(String[|] args) { 
// 创 建 一 封 TEXT 格 式 的 邮件 
MailTemplate m = new HtmlMail("a@a.com","b@b.com","» 
// 创 建 一 个 Mail 发 送 程 序 
MailServer mail = new MailServer(m); 
// 发 送 邮 件 


mail.sendMail(); 





Cy 


运行 结果 如 下 所 示 : 





-=== 正 在 发 送 的 邮件 信息 ==== 











发 件 人 : a@a.com 
收 件 人 : b@b.com 


邮件 标题 : 外 星人 攻击 地 球 了 





邮件 内 容 : 





Content-Type: multipart/mixed;charset=GB2312 





AS 


寺 局 是 外 星人 被 地 球 人 打败 了 |! 





邮件 格式 为 : 超 文本 格式 





当然 ， 如 果 想 产生 一 封 文本 格式 的 邮件 ， 只 要 稍稍 修改 一 下 场景 类 
就 可 以 了 : new HtmlMail 修 改 为 new TextMail， 读 者 可 以 自行 实现 ， 非 
常 简单 。 在 该 场景 中 ， 我 们 使 用 策略 模式 实现 两 种 算法 的 自由 切换 ， 它 
提供 了 这 样 的 保证 : 封装 邮件 的 两 种 行为 是 可 选择 的 ， 至 于 选择 哪个 算 
法 是 由 上 层 模 块 决定 的 。 策 略 模 式 要 完成 的 任务 就 是 提供 两 种 可 以 蔡 换 
的 算法 。 








33.1.2 桥梁 模式 实现 邮件 发 送 


桥梁 模式 关注 的 是 抽象 和 实现 的 分 离 ， 它 是 结构 型 模式 ， 结 构 型 模 
式 研究 的 是 如 何 建立 一 个 软件 染 构 ， 下 面 我 们 就 来 看 看 桥梁 模式 是 如 何 
构件 一 套 友 送 邮 件 的 架构 的 ， 如 图 33-3 所 示 。 


类 图 中 我 们 增加 了 SendMail 和 Postfix 两 个 邮件 服务 器 来 实现 类 ， 在 
邮件 模板 中 允许 增加 发 送 者 标记 ， 其 他 与 策略 模式 都 相同 。 我 们 在 这 里 
已 经 完成 了 一 个 独立 的 架构 ， 邮 件 有 了 ， 发 送 邮 件 的 服务 器 也 具备 了 ， 
是 一 个 完整 的 邮件 发 送 程 序 。 需 要 读者 注意 的 是 ，SendMail 类 不 是 一 个 
动词 行为 (发 送 邮 件 ) ， 它 指 的 是 一 款 开源 邮件 服务 器 产品 ， 一 般 *nix 
系统 的 默认 邮件 服务 器 就 是 SendMail; Postfix 也 是 一 款 开 源 的 邮件 服务 
器 产品 ， 其 性 能 、 稳 定性 都 在 逐步 赶 超 SendMail。 





-MailTemplate m -String from 


+MailServer(MailTemplate _m) 人 
+void sendMail() Sriheeonlent 
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+void add(String sendInfo) 
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+void sendMail() 
’ / +String getContext 
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Postfix 邮 件 服务 器 


图 33-3 桥梁 模式 实现 邮件 发 送 的 类 图 
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Pe 


+String getContext() 


我 们 来 看 代码 实现 ， 邮 件 模板 仅仅 增加 了 一 个 add 方 法 ， 如 代码 清 
单 33-6 所 示 。 


代码 清单 33-6 邮件 模板 


public abstract class MailTemplate { 
水 党 
* 该 部 分 代码 不 变 ， 请 参考 代码 清单 33-1 
< 


// 人 允许 增加 邮件 发 送 标志 

public void add(String sendIinfo)t{ 
context = SendInfo + context 

} 





ww 


文本 邮件 、 超 文本 邮件 都 没有 任何 改变 ， 如 代码 清单 33-2、33-3 所 
示 ， 这 里 不 再 更 述 。 


我 们 来 看 邮件 服务 器 ， 也 就 是 桥梁 模式 的 抽象 化 角色 ， 如 代码 清单 


33-7 上 所 示 。 


代码 清单 33-7 邮件 服务 器 


public abstract class MailServer { 
// 发 送 的 是 哪 封 邮件 
protected final MailTemplate m; 
public MailServer(MailTemplate _m){ 


this.m = _m; 


} 
// 发 送 邮 件 
public void sendMail(){ 


System.out.println("==== 正 在 发 送 的 邮件 信息 ====" ) ; 
// 发 件 人 

System.out.println(" 发 件 人 : " + m.getFrom()); 

// 收 件 人 

System.out.println(" 收 件 人 : " + m.getTo()); 

// 标 题 

System,out,println(" 邮 件 标题 : " + m.getSubject()); 
// 邮 件 内 容 

System,out,println(" 邮 件 内 容 : " + m.getcontext()); 





该 类 相对 于 策略 模式 的 环境 角色 有 两 个 改变 : 


e 修改 为 抽象 类 。 为 什么 要 修改 成 抽象 类 ?因为 我 们 在 设计 一 个 染 
构 ， 邮 件 服务 器 是 一 个 具体 的 、 可 实例 化 的 对 象 吗 ?“ 给 我 一 台 邮 件 服 
务 右 ”能 实现 吗 ? 不 能 ， 只 能 说 “给 我 一 全 Postfix 邮 件 服务 器 >， 这 才 
现 ， 必 须 有 一 个 明确 的 可 指向 对 象 。 


e 变量 mm 修改 为 Protected 访 问 权 限 ， 方 便 子 类 调用 。 


我 们 再 来 看 看 Postfix 邮 件 服 务 器 的 实现 ， 如 代码 清单 33-8 所 示 。 


A 


用 头 


代码 清单 33-8 Postfix 邮 件 服 务 器 


public class Postfix extends MailServer { 
public Postfix(MailTemplate _m) { 
super(_m); 


} 
// 修 正 邮件 发 送 程序 
public void sendMail( ){ 
// 增 加 邮件 服务 器 信息 
String context ="Received: from XXXX (unknown [xxx.x 
super.m.add(context); 
super.sendMail( ); 





为 什么 要 履 写 sendMail 程 序 呢 ? 这 是 因为 每 个 邮件 服务 器 在 发 送 邮 
件 时 都 会 在 邮件 内 容 上 留 下 自己 的 标志 ， 一 是 广告 作用 ， 二 是 为 了 互联 
网 上 统计 需要 ， 三 是 方便 同 质 软件 的 共振 。 我 们 再 来 看 SeandMail 邮 件 服 
务 露 的 实现 ， 如 代码 清单 33-9 所 示 。 





代码 清单 33-9 SendMail 邮 件 服务 器 


public class SendMail extends MailServer { 
// 传 递 一 封 邮件 
public SendMail(MailTemplate _m) { 
super(_m); 


} 

// 修 正 邮 件 发 送 程序 

@Override 

public void sendMail( ){ 
// 增 加 邮件 服务 器 信息 
super.m.add("Received: (sendmail); 7 Nov 2009 04:14: 
super.sendMail( ); 





邮件 和 邮件 服务 器 都 有 了 ， 我 们 来 看 怎么 发 送 邮 件 ， 如 代码 清单 


33-10 所 示 。 


代码 清单 33-10 场景 类 


public class Client { 
public static void main(String[|] args) { 
// 创 建 一 封 TEXT 格 式 的 邮件 
MailTemplate m = new HtmlMail("a@a.com","b@b.com","» 





// 使 用 Postfix 发 送 邮 件 
MailServer mail = new Postfix(m); 
// 发 送 邮件 
mail.sendMail( ); 
} 
上 
运行 结果 如 下 所 示 : 





==== 正 在 发 送 的 邮件 信息 ==== 











发 件 人 : a@a.com 
收 件 人 : b@b.com 
邮件 标题 : 外 星人 攻击 地 球 了 





邮件 内 容 : 





Content-Type: multipart/mixed;charset=GB2312 


Received: from XXXX (unknown [XXXx.XXX.XXX.XXX]) by aaa.aaa.com (Postfix) with ESMT?P id 
8DBCD172B8 





结局 是 外 星人 被 地 球 人 打败 了 ! 





邮件 格式 为 : 超 文 本 格式 


当然 了 ， 还 有 其 他 三 种 发 送 邮件 的 方式 : Postfix 发 送 文本 邮件 以 及 
SendMail 有 发 送 文本 邮件 和 超 文本 邮件 。 修 改 量 很 小 ， 该 者 可 以 目 行 修改 


实现 ， 体 会 一 下 桥 桨 模式 的 特点 。 


33.1.3 最 佳 实 号 


打上 略 模 式 和 桥梁 模式 是 如 此 相似 ， 我们 只 能 从 它们 的 意图 上 来 分 

析 。 和 集 略 模式 是 一 个 行为 模式 ， 骨 在 封装 一 系列 的 行为 ， 在 例子 中 我 们 
认为 把 邮件 的 必要 信息 (发 件 人 、 收 件 人 、 标 题 、 内 容 ) 封装 成 一 个 对 
象 就 是 一 个 行为 ， 封 装 的 格式 〈 算 法) 不 同 ， 行 为 也 就 不 同 。 而 桥梁 模 
式 则 是 解决 在 不 破坏 封装 的 情况 下 如 何 抽取 出 它 的 抽象 部 分 和 实现 音 

分 ， 它 的 前 提 是 不 破坏 封装 ， 让 抽象 部 分 和 实现 部 分 都 可 以 独立 地 变 

化 ， 在 例子 中 ， 我 们 的 邮件 服务 器 和 邮件 模板 是 不 是 都 可 以 独立 地 变 

化 ? 不 管 是 邮件 服务 怖 还 是 邮件 模板 ， 只 要 继承 了 抽象 类 束 可 以 继续 打 - 
展 ， 它 的 主旨 是 建立 一 个 不 破坏 封 效 性 的 可 扩展 架构 。 














简单 来 说 ， 策 略 模式 是 使 用 继承 和 多 态 建立 一 套 可 以 自由 切换 算法 
的 模式 ， 桥 梁 模 式 是 在 不 破坏 封装 的 前 提 下 解决 抽象 和 实现 都 可 以 独立 
扩展 的 模式 。 桥 梁 模 式 必然 有 两 个 “桥墩 "一 一 抽象 化 角色 和 实现 化 角 
色 ， 只 要 桥墩 搭建 好 ， 桥 就 有 了 ， 而 集 略 模式 只 有 一 个 抽象 角色 ， 可 以 
没有 实现 ， 也 可 以 有 很 多 实现 。 











还 是 很 难 区 分 ， 是 吧 ? 多 想 想 两 者 的 意图 ， 就 可 以 理解 为 什么 要 建 
并 两 个 相似 的 模式 了 。 我 们 在 做 系统 设计 时 ， 可 以 不 考虑 到 底 使 用 的 是 





策略 模式 还 是 桥 染 模式 ， 只 要 好 用 ， 能 够 解决 问题 就 成 , “不 管 黑 猫 白 
猫 ， 抓 住 老鼠 的 就 是 好 猫 ”。 


33.2 门面 模式 VS 中 介 者 模式 


门面 模式 为 复杂 的 子 系统 提供 一 个 统一 的 访问 界面 ， 它 定义 的 是 一 
个 局 层 接 口 ， 该 接口 使 得 子 系统 更 加 容易 使 用 ， 避 免 外 部 模块 深入 到 子 
系统 内 部 而 产生 与 子 系统 内 部 细节 耦合 的 问题 。 中 介 者 模式 使 用 一 个 中 
介 对 象 来 封装 一 系列 同事 对 象 的 交互 行为 ， 它 使 各 对 象 之 间 不 再 显 式 地 
引用 ， 从 而 使 其 耦合 松散 ， 建 立 一 个 可 扩展 的 应 用 架构 。 








33.2.1 中 介 者 模式 实现 工资 计算 


大 家 工作 会 得 到 工资 ， 那 么 工资 与 哪些 因素 有 关 呢 ? 这 里 假设 工资 
与 职位 、 税 收 有 关 ， 职 位 提升 工资 就 会 增加 ， 同 时 税收 也 增加 ， 职 位 下 
降 了 工资 也 同步 降低 ， 当 然 税 收 也 降低 。 而 如 果 税 收 比率 增加 了 呢 ? 工 
资 自然 就 减少 了 ! 这 三 者 之 间 两 两 都 有 关系 ， 很 适合 中 介 者 模式 的 场 
景 ， 类 图 如 图 33-4 所 示 。 
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图 33-4 工资 、 职 位 、 税 收 的 示意 类 图 






类 图 中 的 方法 比较 简单 ， 我 们 主要 分 析 的 是 三 者 之 间 的 关系 ， 通 过 
类 图 可 以 发 现 三 者 之 间 已 经 没有 耦合 ， 原 本 在 需求 分 析 时 我 们 发 现 三 者 
有 直接 的 交互 ， 采 用 中 介 者 模式 后 ， 三 个 对 象 之 间 已 经 相互 独立 了 ， 全 
部 委托 中 介 者 完成 。 我 们 在 类 图 中 还 定义 了 一 个 抽象 同事 类 ， 它 是 一 个 
标志 性 接口 ， 其 子 类 都 是 同事 类 ， 都 可 以 极 中 介 者 接收 ， 如 代码 清单 


33-11 所 示 。 








代码 清单 33-11 抽象 同事 类 


public abstract class AbsColleague { 
// 每 个 同事 类 都 对 中 介 者 非常 了 解 
protected AbsMediator mediator ，; 
public AbsColleague(AbsMediator _mediator){ 
this.mediator = _mediator; 
} 

















在 抽象 同事 类 中 定义 了 每 个 同事 类 对 中 介 者 都 非常 了 解 ， 如 此 才能 
把 请 求 委 托 给 中 介 者 完成 。 三 个 同事 类 都 具有 相同 的 设计 ， 即 定义 一 个 
业务 接口 以 及 每 个 对 象 必须 实现 的 职责 ， 同 时 既然 是 同事 类 就 都 继承 
AbsColleague。 抽 象 同事 类 只 是 一 个 标志 性 父 类 ， 并 没有 限制 子 类 的 业 
务 罗 辑 ， 因 此 每 一 个 同事 类 并 没有 违背 单一 职责 原则 。 首 先 来 看 职位 接 
口 ， 如 代码 清单 33-12 所 示 。 























代码 清单 33-12 职位 接口 


public interface IPosition { 
// 升 职 
public void promote() ; 
// 降 职 
public void demote(); 


只 位 会 有 升 有 降 ， 职 位 变化 如 代码 清单 33-13 所 示 。 


代码 清单 33-13 职位 


public class Position extends AbsColleague implements IPosition { 
public Position(AbsMediator _mediator)t{ 
super(_mediator); 


public void demote() { 


Super .mediator.down(this); 


public void promote() { 
super .mediator ,up(this ) 
} 


每 一 个 职位 的 升降 动作 都 委托 给 中 介 者 执行 ， 有 具体 一 个 职位 升降 影 
啊 到 谁 这 里 没有 定义 ， 完 全 由 中 介 者 完成 ， 简 单 而 且 扩展 性 非常 好 。 下 
面 我 们 来 看 工资 接口 ， 如 代码 清单 33-14 所 示 。 





代码 清单 33-14 工资 接口 


public interface ISalary { 
// 加 薪 
public void increaseSalary(); 
// 降 薪 
public void decreaseSalary( ) ， 





工资 也 会 有 升 有 降 ， 如 代码 清单 33-15 所 示 。 


代码 清单 33-15 工资 


public class Salary extends AbsColleague implements ISalary { 
public Salary(AbsMediator _mediator)t{ 
super(_mediator); 


public void decreaseSalary() { 
super .mediator .down(this),; 


public void increaseSalary() { 
super.mediator.up(this); 
} 


交 税 是 公民 的 义务 ， 税 收 接口 如 代码 清单 33-16 所 示 。 


代码 清单 33-16 税收 接口 


public interface ITax { 
// 税 收 上 升 
public void raise(); 
// 税 收 下 降 
public void drop(); 


税收 的 变化 对 我 们 的 工资 当然 有 影响 ， 如 代码 清单 33-17 所 示 。 


代码 清单 33-17 税收 


public class Tax extends AbsColleague implements ITax { 

// 注 入 中 介 者 

public Tax(AbsMediator _mediator)t{ 
super(_mediator); 





} 
public void drop() { 
super .mediator.down(this); 


public void raise() { 
super .mediator .up(this); 
} 


以 上 同事 类 的 业务 都 委托 给 了 中 介 者 ， 其 本 类 已 经 没有 任何 的 逻辑 
了 ， 非 党 简单， 现在 的 问题 是 中 介 者 类 非常 复杂 ， 因 为 它 要 人 处理 三 者 之 
间 的 关系 。 我 们 首先 来 看 抽象 中 介 者 ， 如 代码 清单 33-18 所 示 。 


代码 清单 33-18 抽象 中 介 者 


public abstract class AbsMediator { 
// 工 资 
protected final ISalary salary; 
// 职 位 
protected final IPosition position; 


// 税 收 


protected final ITax tax; 

public AbsMediator(){ 
salary = new Salary(this); 
position = new Position(this); 
tax = new Tax(this); 





} 

// 工 资 增加 了 

public abstract void up(ISalary _salary); 

// 职 位 提升 了 

public abstract void up(IPosition _position); 
// 税 收 增加 了 

public abstract void up(ITax _tax); 

// 工 资 降低 了 

public abstract void down(ISalary _salary); 
// 职 位 降低 了 

public abstract void down(IPosition _position); 
// 税 收 降低 了 


public abstract void down(ITax _tax); 





在 抽象 中 介 者 中 我 们 定义 了 6 个 方法 ， 分 别处 理 职位 升降 、 工 资 升 
降 以 及 税收 升降 的 业务 逻辑 ， 采 用 Java 多 态 机 制 来 实现 ， 我 们 来 看 实现 
类 ， 如 代码 清单 33-19 所 示 。 


代码 清单 33-19 中 介 者 


public class Mediator extends AbsMediatort{ 
// 工 资 增加 了 
public void up(ISalary _salary) { 
upSalary(); 
upTax( ) ; 


} 

// 职 位 提升 了 

public void up(IPosition position) { 
upPosition(); 
upSalary( ); 
upTax( ); 


} 

// 税 收 增加 了 

public void up(ITax tax) { 
upTax( ) ; 
downSalary( ) ; 
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/* 

* 工 资 、 职 位 、 税 收 降低 的 处 理 方法 相同 ， 不 再 资 述 
4 

// 工 资 增加 





private void upSalary()t{ 
System.out.println(" 工 资 翻 倍 ， 乐 翻天 ")，; 
} 


private void upTax(){ 
System.out,printJIn(" 税 收 上 升 ， 为 国家 做 贡献 " ); 
} 


private void upPosition(){ 
System.out.println(" 职 位 上 升 一 级 ， 狂 喜 "); 
} 


private void downSalary(){ 
System.out.println(" 经 济 不 景气 ， 降 低 工资 ")， 





private void downTax(){ 
System.out.printlin(" 税 收 减 低 ， 国 家 收入 减少 ")， 
} 


private void downPostion(){ 
System.out,println(" 官 降 三 级 ， 比 自杀 还 痛 若 " ) ; 














} 
} 

该 类 的 方法 较 多 ， 但 是 还 是 非常 简单 的 ， 它 的 12 个 方法 分 为 两 大 类 
型 ， 一 类 是 每 个 业务 的 独立 流程 ， 比 如 增加 工资 ， 仅 仅 实现 单独 增加 工 





资 的 职能 ， 而 不 关心 职位 、 税 收 是 如 何 变化 的 ， 该 类 型 的 方法 是 private 
私有 类 型 ， 只 能 提供 本 类 内 访问 ; 另 一 类 是 实现 抽象 中 介 者 定义 的 方 
法 ， 完 成 具体 的 每 一 个 逻辑 ， 比 如 职位 上 升 ， 同 时 也 引起 了 工资 增加 、 
税收 增加 。 我 们 编写 一 个 场景 类 ， 看 看 运行 结果 ， 如 代码 清单 33-20 所 
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代码 清单 33-20 场景 类 


public class Client { 
public static void main(String[] args) { 


// 定 义 中 介 者 

Mediator mediator = new Mediator(); 

// 定 义 各 个 同事 类 

IPosition position = new Position(mediator); 
ISalary salary = new Salary(mediator ); 

ITax tax = new Tax(mediator ); 

// 职 位 提升 了 
System,out,.printlLn("=== 职 位 提升 ===") ， 
position,promote( ); 


ww 


运行 结果 如 下 所 示 : 


-=== 职 位 提升 === 
职位 上 升 一 级 ， 狂 喜 
工资 翻 倍 ， 乐 翻天 


税收 上 升 ， 为 国家 做 贡献 


我 们 回 过 头 来 分 析 一 下 设计 ， 在 接收 到 需求 后 我 们 发 现职 位 、 工 
资 、 税 收 之 间 有 着 紧密 的 焰 合 关系 ， 如 果 不 玉 用 中 介 者 模式 ， 则 每 个 对 
象 都 要 与 其 他 两 个 对 象 进行 通信 ， 这 势必 会 增加 系统 的 复杂 性 ， 同 时 也 
使 系统 处 于 僵化 状态 ， 很 难 实现 拥抱 变化 的 理想 。 通 过 增加 一 个 中 介 
者 ， 每 个 同事 类 的 职位 、 工 资 、 税 收 都 只 与 中 介 者 通信 ， 中 介 者 封装 了 
各 个 同事 类 之 间 的 逻辑 关系 ， 方 便 系 统 的 扩展 和 维护 。 








33.2.2 门面 模式 实现 工资 计算 





工资 计算 是 一 件 非 常 复杂 的 事情 ， 简 单 来 说 ， 它 是 对 基本 工资 、 月 








奖金、 岗位 津贴 、 绩 效 、 考 勒 、 税 收 、 福 利 等 因素 综合 运算 后 的 一 个 数 
字 。 即 使 设计 一 个 HR〈 人 力 资 源 ) 系统 ， 员 工 工 资 计算 也 是 非常 复杂 
的 模块 ， 但 是 对 于 外 界 ， 比 如 高 管 层 ， 最 希望 看 到 的 结果 是 张 三 拿 了 多 
少 钱 ， 李 四 和 拿 了 多 少 钱 ， 而 不 是 看 中 间 的 计算 过 程 ， 怎 么 计算 那 是 人 事 
部 门 的 事情 。 换 名 话说， 对 外 界 的 访问 者 来 说 ， 它 只 要 传递 进去 一 个 人 
员 名 称 和 月 份 即 可 获得 工资 数 ， 而 不 用 关心 其 中 的 计算 有 多 么 复杂 ， 这 
就 用 得 上 门面 模式 了 。 

















门面 模式 对 子 系统 起 封装 作用 ， 它 可 以 提供 一 个 统一 的 对 外 服务 接 
口 ， 如 图 33-5 所 示 。 


HRFacade 


+int querySalary(String name, Date date) 
+int queryWorkDays(String name) 


Attendance 
=== 


+int getWorkDays() 




















SalaryProvider 






ry() 





+int totalSala 












Performance 


+mnt getPerformanceValue() 





BasicSalary 


+int getBasicSalary() 


+int getBonus() 


ea ks i 
奖金 绩效 





图 33-5 HR 系统 的 类 图 











该 类 图 主要 实现 了 工资 计算 ， 通 过 HRFacade 门 面 可 以 查询 用 户 的 
工资 以 及 出 勤 天 数 等 ， 而 不 用 关心 这 个 工资 或 者 出 勤 天 数 是 怎么 计算 出 
来 的 ， 从 而 屏蔽 了 外 系统 对 工资 计算 模块 的 内 部 细节 依赖 。 我 们 先 看 子 


系统 内 部 的 各 个 实现 ， 考 勤 情 况 如 代码 清单 33-21 所 示 。 


代码 清单 33-21 考勤 情况 


public class Attendance { 
// 得 到 出 勤 天 数 
public int getwWorkDays()t{ 
return (new Random()).nextInt(30); 
} 


非常 简单 ， 只 用 一 个 方法 获得 一 个 员工 的 出 勤 天 数 
金 计 算 ， 如 代码 清单 33-22 所 示 。 


代码 清单 33-22 奖金 计算 


public class Bonus { 
// 考 勤 情况 
private Attendance atte = new Attendance( ) ; 
// 奖 金 
public int getBonus()t{ 
/ v 











int workDays = atte.getworkDays( ); 
// 奖 金 计算 模型 

int bonus = workDays * 1800 / 30; 
return bonus; 


。 我 们 再 来 看 奖 


我 们 在 这 里 实现 了 一 个 示意 方法 ， 实 际 的 奖金 计算 是 非常 复杂 的 ， 


与 考勤 、 绩 效 、 基 本 工资 、 岗 位 都 有 关系 ， 单 单一 个 奖金 计算 就 可 以 设 
计 出 一 个 门面 。 我 们 再 来 看 基本 工资 ， 这 个 基本 上 是 按照 职位 而 定 的 ， 
比较 固定 ， 如 代码 清单 33-23 所 示 。 





代码 清单 33-23 基本 工资 


public class BasicSalary { 
// 获 得 一 个 人 的 基本 工资 
public int getBasicSalary()t{ 
return 2000 ， 
} 








我 们 定义 了 员工 的 基本 工资 都 为 2000 元 ， 没 有 任何 浮动 的 余地 。 再 
来 看 绩效 ， 如 代码 清单 33-24 所 示 。 


代码 清单 33-24 绩效 


public class Performance { 








// 基 本 工资 
private BasicSalary salary = new BasicSalary(); 
// 绩 效 奖励 
public int getPerformanceValue(){ 
// 随 机 绩效 


int perf = (new Random()).nextInt(100); 
return salary.getBasicSalary() * perf /100; 


绩效 按照 一 个 非常 简单 的 算法 ， 即 基本 工资 乘 以 一 个 随机 的 百 分 
比 。 我 们 再 来 看 税收 ， 如 代码 清单 33-25 所 示 。 


代码 清单 33-25 税收 


public class Tax { 
// 收 取 多 少 税金 
public int getTax()t{ 
// 交 纳 一 个 随机 数量 的 税金 
return (new Random()).nextInt(300); 








一 个 计算 员工 薪酬 的 所 有 子 元 系 都 已 经 具备 了 ， 剩 下 的 就 是 编写 组 
合 丈 辑 类 ， 总 工资 的 计算 如 代码 清单 33-26 所 示 。 


代码 清单 33-26 总 工资 计算 


public class SalaryProvider { 
// 基 本 工资 
private BasicSalary basicSalary = new BasicSalary(); 
// 奖 金 
private Bonus bonus = new Bonus(); 
// 绩 效 
private Performance perf = new Performance(); 
// 税 收 
private Tax tax = new Tax(); 
// 获 得 用 户 的 总 收入 
public int totalSalary()t{ 
return basicSalary.getBasicSalary() + bonus.getBonus 
} 














里 只 是 对 前 面 的 元 素 值 做 了 一 个 加 减法 计算 ， 这 是 对 实际 HR 系 
统 的 简化 处 理 ， 如 果 把 这 个 类 暴露 给 外 系统 ， 那 么 被 修改 的 风险 是 非常 
大 的 ， 因 为 它 的 方法 totalSalary 是 一 个 具体 的 业务 逻辑 。 我 们 采用 门面 
模式 的 目的 是 要 求 门面 是 无 逻辑 的 ， 与 业务 无 关 ， 只 是 一 个 子 系统 的 访 
问 入 口 。 门 面 模式 只 是 一 个 技术 层次 上 的 实现 ， 全 部 业务 还 是 在 子 系统 
内 实现 。 我 们 来 看 HR 门面 ， 如 代码 清单 33-27 所 示 。 








代码 清单 33-27 HR 门面 


public class HRFacade { 
// 总 工资 情况 
private SalaryProvider salaryProvider = new SalaryProvider( 
// 考 勤 情况 
private Attendance attendance = new Attendance( ) ; 
// 查 询 一 个 人 的 总 收入 
public int querySalary(String name,Date date)t{ 

return SalaryProvider ,totalSalary( ); 


} 

// 查 询 一 个 员工 一 个 月 工作 了 多 少 天 

public int queryWorkDays(String name)t{ 
return attendance ,getworkDays( ) ; 

} 














所 有 的 行为 都 是 委托 行为 ， 由 具体 的 子 系统 实现 ， 门 面 只 是 提供 了 
一 个 统一 访问 的 基础 而 已 ， 不 做 任何 的 校 验 、 判 新 、 弄 和音 等 处 理 。 我 们 
编写 一 个 场景 类 奋 看 运行 结果 ， 如 代码 清单 33-28 所 示 。 








代码 清单 33-28 场景 类 


public class Client { 
public static void main(String[|] args) { 
// 定 义 门 面 
HRFacade facade = new HRFacade( ); 
System.out.println("=== 外 系统 查询 总 收入 ===" ); 
int salary = facade.querySalary(" 张 三 ", new Date(Syste 
currentTimeMillis())); 

System,out,.println( " 张 三 11 月 总 收入 为 : " +salary); 
// 再 查询 出 勤 天 数 
System.out.println("\n=== 外 系统 查询 出 勤 天 数 ===" )， 
int workDays = facade.queryworkDays(" 李 四 ")，; 
System.out.println(" 李 四 本 月 出 勤 : " +workDays ) ; 
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运行 结果 如 下 所 示 : 


=== 外 系统 查询 总 收入 === 





张 三 11 月 总 收入 为 : 4133 
=== 外 系统 查询 出 勤 天 数 === 








李 四 本 月 出 勤 : 22 





在 该 例 中 ， 我 们 使 用 了 门面 模式 对 薪水 计算 子 系统 进行 封装 ， 避 免 
子 系统 内 部 复杂 逻辑 外 泄 ， 确 保 子 系统 的 业务 逻辑 的 单纯 性 ， 即 使 业务 
流程 需要 变更 ， 影 响 的 也 是 子 系统 内 部 功能 ， 比 如 奖金 需要 与 基本 工资 
挂钩 ， 这 样 的 修改 对 外 系统 来 说 是 透明 的 ， 只 需要 子 系统 内 部 变更 即 
可 。 





33.2.3 最 佳 实践 


门面 模式 和 中 介 者 模式 之 间 的 区 别 还 是 比较 明显 的 ， 门 面 模式 是 以 
封装 和 隔离 为 主要 任务 ， 而 中 介 者 模式 则 是 以 调和 同事 类 之 间 的 关系 为 
主 ， 因 为 要 调和 ， 所 以 具有 了 部 分 的 业务 逻辑 控制 。 两 者 的 主要 区 别 如 
下 : 


e 功能 区 别 


门面 模式 只 是 增加 了 一 个 门面 ， 它 对 子 系统 来 说 没有 增加 任何 的 功 
能 ， 子 系统 天 脱离 门面 模式 是 完全 可 以 独立 运行 的 。 而 中 介 者 模式 则 增 
加 了 业务 功能 ， 它 把 各 个 同事 类 中 的 原 有 耦合 关系 移植 到 了 中 介 者 ， 同 


事 类 不 可 能 脱离 中 介 者 而 独立 存在 ， 除 非 是 想 增 加 系统 的 复杂 性 和 降低 
扩展 性 。 


e 知晓 状态 不 同 


对 门面 模式 来 说 ， 子 系统 不 知道 有 门面 存在 ， 而 对 中 介 者 来 说 ， 每 
个 同事 类 都 知道 中 介 者 存在 ， 因 为 要 依靠 中 介 者 调和 同事 之 间 的 关系 ， 
它们 对 中 介 者 非常 了 解 。 


。 封 装 程度 不 同 


门面 模式 是 一 种 简单 的 封装 ， 所 有 的 请 求 处 理 都 委托 给 子 系 统 完 
成 ， 而 中 介 者 模式 则 需要 有 一 个 中 心 ， 由 中 心 协 调 同事 类 完成 ， 并 且 中 
心 本 映 也 完成 部 分 业务 ， 它 属于 更 进一步 的 业务 功能 封装 。 


33.3 包装 模式 群 PK 





我 们 讲 了 这 么 多 的 设计 模式 ， 大 家 有 没有 发 觉 在 很 多 的 模式 中 有 些 
角色 是 不 干 活 的 ? 它们 只 是 充当 黔 首 作 用 ， 你 有 问题 ， 找 我 ， 但 我 不 处 
理 ， 我 让 其 他 人 处 理 。 最 典型 的 就 是 代理 模式 了 ， 代 理 角 色 接 收 请 求 然 
后 传递 到 被 代理 角色 处 理 。 门 面 模式 也 是 一 样 ， 门 面 角色 的 任务 就 是 把 
请 求 转 发 到 子 系统 。 类 似 这 种 结构 的 模式 还 有 很 多 ， 我 们 先 给 这 种 类 型 
的 模式 定义 一 个 名 字 ， 叫 做 包装 模式 (wrapping pattern) 。 注 意 ， 包 装 
模式 是 一 组 模式 而 不 是 一 个 。 包 装 模 式 包括 哪些 设计 模式 呢 ?” 包 装 模 式 
包括 : 装饰 模式 、 适 配器 模式 、 门 面 模式 、 代 理 模 式 、 桥 粱 模式。 下 面 
我 们 通过 一 组 例子 来 说 明 这 五 个 包装 模式 的 区 别 。 





33.3.1 代理 模式 








现在 很 多 明星 都 有 经 纪 人 ， 一 般 有 什么 事 他 们 都 会 说 : “你 找 我 的 
经 纪 人 谈 好 了 ”， 下面 我 们 就 看 看 这 一 过 程 怎 么 模拟 。 假 设 有 一 个 追星 
族 想 找 明星 签字 ， 我 们 看 看 采用 代理 模式 怎么 实现 。 代 理 模 式 是 包装 模 
式 中 的 最 一 般 的 实现 ， 类 图 如 图 33-6 所 示 。 















<<Interface>> 
IStar 
TREE 
+Vold sign() 


入 


IIS 
TIdolater 





类 图 很 简单 ， 就 是 一 个 简单 的 代理 模式 ， 我 们 来 看 明星 的 定义 ， 明 
星 接 口 如 代码 清单 33-29 所 示 。 


代码 清单 33-29 明星 接口 


public interface IStar { 
// 明 星 都 会 签名 
public void sign(); 





明星 只 有 一 个 行为 : 签字 。 我 们 来 看 明星 的 实现 ， 如 代码 清单 33- 


代码 清单 33-30 明星 


public class Singer implements IStar { 
public void sign() { 
System.out.println(" 明 星 签 字 : 我 是 XXX 大 明星 " ) ; 

















经 纪 人 与 明星 应 该 有 相同 的 行为 ， 比 如 说 签名 ， 虽 然 经 纪 人 不 签 
名 ， 但 是 他 把 你 要 签名 的 笔记 本 、 衣 服 、CD 等 传递 过 去 让 真正 的 明星 
签字 ， 经 纪 人 如 代码 清单 33-31 所 示 。 


代码 清单 33-31 经 纪 人 


public class Agent implements IStar { 
// 定 义 是 谁 的 经 纪 人 
private IStar star; 











// 构 造 函 数 传递 明星 
public Agent(IStar _star)t{ 
this.star = _star; 


// 经 纪 人 是 不 会 签字 的 ， 签 字 了 歌迷 也 不 认 

public void sign() { 
star.sign( ); 

} 


应 该 非常 明确 地 指出 一 个 经 纪 人 是 谁 的 代理 ， 因 此 要 在 构造 函数 中 
接收 一 个 明星 对 象 ， 确 定 是 要 做 这 个 明星 的 代理 。 我 们 再 来 看 看 追星 族 
么 找 明 星 签字 的 ， 如 代码 清单 33-32 所 示 。 


代码 清单 33-32 追星 族 


public class Idolater { 

public static void main(String[|] args) { 
// 崇 拜 的 明星 是 谁 
IStar star = new Singer(); 
// 找 到 明星 的 经 纪 人 
IStar agent = new Agent(star); 
System.out.println(" 追 星 族 : 我 是 你 的 崇拜 者 ， 请 签名 ! ") ; 
// 签 字 
agent .Sign() ; 





























很 简单 ， 找 到 明星 的 代理 ， 然 后 明星 束 签 字 了 。 运 行 结果 如 下 所 


追星 族 : 我 是 你 的 深 拜 者 ， 请 签名 ! 








明星 签字 : 我 是 XXX 大 明星 





看 看 我 们 的 程序 多 辑 ， 我 们 是 找 明 星 的 经 纪 人 签字 ， 真 实 签字 的 是 
明星 ， 经 纪 人 只 是 把 这 个 请 求 传递 给 明星 处 理 和 而已， 这 是 普通 的 代理 模 
式 的 典型 应 用 。 





33.3.2 装饰 模式 


明星 也 都 是 一 步 一 步 地 奋斗 出 来 的 ， 谁 都 不 是 一 步 就 成 为 大 明星 
的 。 甚 至 一 些 演 员 通 过 粉饰 自己 给 观众 一 个 好 的 印象 ， 现 在 我 们 就 来 看 
怎么 粉饰 一 个 演员 ， 如 图 33-7 所 示 。 


<<mterface>> 
IStar 


+void act() 









-[Star star 


+Decorator(IStar star) 
+void act() 
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| 
+Deny(IStar star) 
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图 33-7 演技 修饰 


下 面 我 们 就 来 看 看 这 些 过 程 如何 实 现 ， 先 看 明星 接口 ， 如 代码 清单 
33-33 所 示 。 


代码 清单 33-33 明星 接口 


public interface IStar { 
// 演 戏 


public void act(); 


我 们 来 看 看 我 们 的 主角 ， 如 代码 清单 33-34 所 示 。 


代码 清单 33-34 假 明 星 


public class FreakStar implements IStar { 
public void act() { 
System.out ,println(" 演 中 : 演技 很 拙劣 ") ， 
} 


我 们 看 看 这 个 明星 是 怎么 粉饰 的 ， 先 定义 一 个 抽象 装饰 类 ， 如 代码 
清单 33-35 所 示 。 


代码 清单 33-35 抽象 装饰 类 


public abstract class Decorator implements IStar { 
// 粉 饰 的 是 谁 
private IStar star; 
public Decorator(IStar _star)t 
this.star = _star,; 





} 

public void act() { 
this.star.act(); 

} 


前 后 两 次 修饰 ， 开 演 前 早 无 尽 悦 地 吹 唾 ， 如 代码 清单 33-36 所 示 。 


代码 清单 33-36 吹 大 话 


public class HotAir extends Decorator { 
public HotAir(IStar _star)t{ 
super(_star); 


} 
public void act(){ 


System.out.println(" 演 前 : 夸 夸 其 谈 ， 没 有 自己 不 能 演 的 角色 " ) 
super.act(); 








大 家 发 现 这 个 明星 演技 不 好 的 时 候 ， 他 拼命 找 借口 ， 说 是 那天 天 气 
不 好 、 心 情 不 好 等 ， 如 代码 清单 33-37 所 示 。 


代码 清单 33-37 抵赖 


public class Deny extends Decorator { 
public Deny(IStar _star)t{ 
super(_star); 


} 
public void act(){ 
super .act( ); 


System.out.println(" 演 后 ; 百般 抵赖 ， 死 不 承认 "); 


我 们 建立 一 个 场景 把 这 种 情况 展示 一 下 ， 如 代码 清单 33-38 所 示 。 


代码 清单 33-38 场景 类 


public class Client { 
public static void main(String[] args) { 

// 定 义 出 所 谓 的 明星 
IStar freakStar = new FreakStar(); 
// 看 看 他 是 怎么 粉饰 自己 的 
// 演 前 吹 星 自 己 无 所 不 能 
freakStar = new HotAir(freakStar ) 
// 演 完 后 ， 死 不 承认 自己 演 的 不 好 
freakStar = new Deny(freakStar); 
System.out.println("==== 看 看 一 些 虚假 明星 的 形象 ====" )， 
freakStar.act( ); 
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运行 结果 如 下 所 示 : 





==== 看 看 一 些 虚假 明星 的 形象 ==== 








演 前 : 夸 夸 其 谈 ， 没 有 自己 不 能 演 的 角色 




















演 中 : 演技 很 拙劣 
演 后 : 百般 抵赖 ， 死 不 承认 


33.3.3 适配器 模式 





我 们 知道 在 演艺 奖 中 还 存在 一 种 情况 : 人 答 身 ， 答 号 也 是 演员 ， 只 是 
普通 的 演员 而 已 ， 在 一 段 戏 中 ， 前 十 五 分 钟 是 明星 本 人 ， 后 十 五 分 钟 也 
古 明 星 本 人 ， 惑 中 间 的 五 分 钟 是 丛 身 ， 那 这 个 场景 该 怎么 描述 呢 ? 注意 

星 


演员 ， 我 们 来 





中 间 那 五 分 钟 ， 这 个 时 候 一 个 普通 演员 被 导演 认为 是 明 
看 类 图 ， 如 图 33-8 所 示 。 
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导演 找 了 一 个 普通 演员 作为 明星 的 符号 ， 不 过 观众 看 到 的 还 是 明星 
的 号 份 。 我 们 来 看 代码 ， 首 移 看 明星 接口 ， 如 代码 清单 33-39 所 示 。 


代码 清单 33-39 明星 接口 


public interface IStar { 
// 明 星 都 要 演戏 
public void act(String context); 








再 来 看 一 个 具体 的 电影 明星 ， 他 的 主要 职责 就 是 演戏 ， 如 代码 清单 


33-40 所 示 。 


代码 清单 33-40 电影 明星 


public class FilmStar implements IStar { 
public void act(String context) { 


System.out.println(" 明 星 演戏 : " + context); 
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我 们 再 来 看 普通 演员 ， 明 星 就 那么 多 ,但 是 普 


看 其 接口 ， 如 代码 清单 33-41 所 示 。 


代码 清单 33-41 普通 演员 接口 


public interface IActor { 
// 普 通 演员 演戏 
public void playact(String contet); 











普通 演员 也 是 演员 ， 是 要 演戏 的 ， 我 们 来 看 一 


如 代码 清单 33-42 所 示 。 


通 演 员 非 常 多 ， 我 们 


个 普通 演员 的 实现 ， 


代码 清单 33-42 普通 演员 
public class UnknownActor implements IActor { 
普通 演员 演戏 
public void playact(String context) { 
System.out.println(" 普 通 演员 : "+context ) ; 
} 


我 们 来 看 蔡 身 该 怎么 编写 ， 如 代码 清单 33-43 所 示 。 


代码 清单 33-43 替身 演员 


public class Standin implements IStar { 
private IActor actor; 





// 蔡 身 是 谁 

public Standin(IActor _actor)t{ 
this.actor = _actor; 

} 


public void act(String context) { 
actor .playact(context); 
} 


这 是 一 个 通用 的 蔡 身 ， 哪 个 普通 演员 能 担任 哪个 明星 的 替身 是 由 导 
演 决 定 的 ， 导 演 想 让 谁 当 就 让 谁 当 ， 我 们 来 看 导演 ， 如 代码 清单 33-44 
所 示 。 


代码 清单 33-44 导演 类 


public class direcotr { 
public static void main(String[|] args) { 
System. out. println( T======= 潜 演戏 过 十 程 模拟 ==========" ) 
// 定 义 一 个 大 明星 
IStar star = new FilmStar(); 
star .act(" 前 十 五 分 钟 ， 明 星 本 人 演戏 " ); 
// 导 演 把 一 个 普通 演员 当做 明星 演员 来 用 


IActor actor = new UnknownActor(); 














IStar standin= new Standin(actor ) 
standin.act(" 中 间 五 分 钟 ， 蔡 身 在 演戏 " ) ; 
star.act(" 后 十 五 分 钟 ， 明 星 本 人 演戏 " ) ; 


ww 




















明星 演戏 : 前 十 五 分 钟 ， 明 星 本 人 演戏 























普通 演员 : 中 间 五 分 钟 ， 替 身 在 演戏 














明星 演戏 : 后 十 五 分 钟 ， 明 星 本 人 演戏 








这 里 使 用 了 适配器 模式 ， 把 一 个 普通 的 演员 转换 为 一 个 明星 演员 。 


33.3.4 桥梁 模式 





我 们 继续 说 明星 圈 的 事情 ， 现 在 明星 类 型 太 多 了 ， 比 如 电影 明星 、 
电视 明星 、 歌 星 、 体 育 明星 、 网 络 明星 等 ， 每 个 类 型 的 明星 都 有 明确 的 
职责 ， 电 影 明星 的 主要 工作 就 是 演 电影 ， 电 视 明 星 的 主要 工作 就 是 演 电 
视 剧 或 者 主持 电视 节目 。 再 看 看 现在 的 明星 ， 单 一 发 展 的 基本 没有 ， 主 
持 人 出 专辑 、 体 育 明 星 演 电影 、 歌 星 拍戏 等 太平 常 了 ， 我 们 就 用 程序 来 
表现 一 下 多 元 化 情形 ， 如 图 33-9 所 示 。 
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+void desc() 
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Pn +AbstractStar(AbsAction action) 
+Vold doJob() 
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图 33-9 各 类 明星 摘 述 


图 33-9 中 定义 了 一 个 抽象 明星 AbsStar， 然 后 产生 出 各 个 具体 类 型 的 
明星 ， 比 如 电影 明星 FilmStar、 歌 星 Singer， 当 然 还 可 以 继续 扩展 下 去 。 
这 里 还 定义 了 一 个 抽象 的 行为 AbsAction， 描 述 明星 所 具有 的 活动 ， 比 
如 演 电影 、 唱 歌 等 ， 在 这 种 设计 下 ， 明 星 可 以 扩展 ， 明 星 的 活动 也 可 以 
扩展 ， 非 常 灵活 。 我 们 先 来 看 明星 的 活动 ， 抽 象 活动 如 代码 清单 33-45 





所 示 。 


代码 清单 33-45 抽象 活动 


public abstract class AbsAction { 
// 每 个 活动 都 有 描述 


public abstract void desc() ; 

















很 简单 ， 只 有 一 个 活动 的 描述 ， 由 子 类 来 实现 。 我 们 来 看 演 电影 和 
唱歌 两 个 活动 ， 分 别 如 代码 清单 33-46、33-47 所 示 。 


代码 清单 33-46 演 电 影 


public class ActFilm extends AbsAction { 
public void desc() { 
System.out .printlin(" 演 出 精彩 绝伦 的 电影 ")， 
} 





代码 清单 33-47 唱歌 


public class Sing extends AbsAction { 
public void desc() { 
System.out.printLn(" 唱 出 优美 的 歌曲 " ) ; 
} 








各 种 精彩 的 活动 都 有 了 ， 我 们 再 来 看 抽象 明星 ， 它 是 所 有 明星 的 代 
表 ， 如 代码 清单 33-48 所 示 。 
代码 清单 33-48 抽象 明星 


public abstract class AbsStar { 
// 一 个 明星 参加 哪些 活动 





protected final AbsAction action; 

// 通 过 构造 函数 传递 具体 活动 

public AbsStar(AbstAction _action){ 
this.action = _action; 


} 

// 每 个 明星 都 有 自己 的 主要 工作 

public void doJob(){ 
action,desc( ) ， 

} 




















明星 都 有 自己 的 主要 活动 (或 者 是 主要 工作 〉 ， 我 们 在 抽象 明星 中 
只 是 定义 明星 有 活动 ， 具 体 有 什么 活动 由 各 个 子 类 实现 。 我 们 再 来 看 电 
影 明 星 ， 如 代码 清单 33-49 所 示 。 








代码 清单 33-49 电影 明星 


public class FilmStar extends AbsStar { 
// 默 认 的 电影 明星 的 主要 工作 是 拍 电 影 
public FilmStar()t{ 
super(new ActFilm( )); 


} 

// 也 可 以 重新 设置 一 个 新 职 、 

public FilmStar(AbsAction _action){ 
super(_action); 


























} 

// 细 化 电影 明星 的 职责 

public void doJob(){ 
System.out.printlin("\n====== 影 星 的 工作 =====" ) ， 





super .doJob( ); 








电影 明星 的 本 职工 作 就 应 该 是 演 电 影 ， 因 此 残 有 了 一 个 无 参 构造 函 
数 来 定义 电影 明星 的 默认 工作 ， 如 有 果 明 星 要 客串 一 下 去 唱歌 也 可 以 ， 有 
参 构造 解决 了 该 问题 。 歌 星 的 实现 与 此 相同 ， 如 代码 清单 33-50 所 示 。 





代码 清单 33-50 歌星 


public class Singer extends AbsStar { 
// 歌 星 的 默认 活动 是 唱歌 
public Singer(){ 
super(new Sing()); 


} 

// 也 可 以 重新 设置 一 个 新 职 、 

public Singer(AbsAction _action)t{ 
super(_action); 














} 

// 细 化 歌星 的 职责 

public void doJob(){ 
System.out.println("\n====== 歌 星 的 工作 





super .doJob() ; 








我 们 使 用 电影 明星 和 歌星 来 作为 代表 ， 这 两 类 明星 也 是 我 们 经 种 听 
到 或 看 到 的 ， 下 面 建立 一 个 场景 类 来 模拟 一 下 明星 的 事迹 ， 如 代码 清单 





33-51 所 示 。 


代码 清单 33-51 场景 类 


public class Client { 

public static void main(String[] args) { 
// 声 明 一 个 电影 明星 
AbsStar zhangSan = new FilmStar(); 
// 声 明 一 个 歌星 
AbsStar liSi = new Singer(); 
// 展 示 一 下 各 个 明星 的 主要 工作 
zhangSan ,doJob() ; 
1iSi.doJob(); 
// 当 然 ， 也 有 部 分 明星 不 务 正业 ， 比 如 歌星 演戏 
1iSi = new Singer(new ActFilm()); 
1iSi.doJob( ); 


Il 
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运行 结果 如 下 所 示 : 


====== 影 星 的 工作 ===== 





演出 精彩 绝伦 的 电影 
= 
唱 出 优美 的 歌曲 
= 














演出 精彩 绝伦 的 电影 











好 了 ， 各 类 明星 都 有 自己 的 本 职工 作 ， 但 是 偶尔 客串 一 个 其 他 类 型 
的 活动 也 是 允许 的 ， 如 此 设计 后 ， 明 星 就 可 以 不 用 固定 在 自己 的 本 职工 
作 上 ， 而 是 向 其 他 方 辐 发 展 ， 比 如 影视 歌 三 栖 明 星 。 


门面 模式 我 们 在 其 他 章节 已 经 讲解 得 比较 多 了 ， 本 小 节 就 不 再 歼 


33.3.5 最 佳 实 践 








5 个 包装 模式 是 大 家 在 系统 设计 中 经 常会 用 到 的 模式 ， 它 们 具有 相 
似 的 特征 : 都 是 通过 委托 的 方式 对 一 个 对 象 或 一 系列 对 象 〈 例 如 门面 模 
式 ) 施行 包 效 ， 有 了 人 包装， 设计 的 系统 才 更 加 灵活 、 稳 定 ， 并 且 极 具 扩 
展 性 。 从 实现 的 角度 来 看 ， 它 们 都 是 代理 的 一 种 具体 表现 形式 ， 我 们 来 
看 看 它们 在 使 用 场景 上 有 什么 区 别 。 


代理 模式 主要 用 在 不 希望 展示 一 个 对 象 内 部 细节 的 场景 中 ， 比 如 一 











个 远程 服务 不 需要 把 远程 连接 的 所 有 细节 都 暴露 给 外 部 模块 ， 通 过 增加 
一 个 代理 类 ， 可 以 很 轻松 地 实现 被 代理 类 的 功能 封装 。 此 外 ， 代 理 模 式 
还 可 以 用 在 一 个 对 象 的 访问 需要 限制 的 场景 中 ， 比 如 AOP。 








装饰 模式 是 一 种 特殊 的 代理 模式 ， 它 倡导 的 是 在 不 改变 接口 的 前 提 
下 为 对 象 增 强 功能 ， 或 者 动态 添加 额外 职责 。 惑 扩展 性 而 言 ， 它 比 子 类 
更 加 灵活 ， 例 如 在 一 个 已 经 运行 的 项 目 中 ， 可 以 很 轻松 地 通过 增加 装饰 
类 来 扩展 系统 的 功能 。 





适配器 模式 的 主要 意图 是 接口 转换 ， 把 一 个 对 象 的 接口 转换 成 系统 
希望 的 妨 外 一 个 接口 ， 这 里 的 系统 指 的 不 仅仅 是 一 个 应 用 ， 也 可 能 是 系 
个 环境 ， 比 如 通过 接口 转换 可 以 屏蔽 外 界 接口 ， 以 免 外 界 接口 深入 系统 
内 部 ， 从 而 提高 系统 的 稳定 性 和 可 靠 性 。 








桥梁 模式 是 在 抽象 层 产 生 厢 合 ， 解 决 的 是 目 行 扩展 的 问题 ， 它 可 以 
使 两 个 有 耦合 关系 的 对 象 互 不 影响 地 扩展 ， 比 如 对 于 使 用 笔画 图 这 样 的 
需求 ， 可 以 采用 桥梁 模式 设计 成 用 什么 笔 〈 铅 笔 、 毛 笔 ) 男 什么 图 〈 同 
形 、 方 形 ) 的 方案 ， 至 于 以 后 需求 的 变更 ， 如 增加 笔 的 类 型 ， 增 加 图 形 


等 ， 对 该 设计 来 说 是 小 菜 一 碟 。 





门面 模式 是 一 个 粗 粒度 的 封装 ， 它 提供 一 个 方便 访问 子 系统 的 接 
口 ， 不 具有 任何 的 业务 逻辑 ， 仅 仅 是 一 个 访问 复杂 系统 的 快速 通道 ， 没 
有 它 ， 子 系统 照样 运行 ， 有 了 它 ， 只 是 更 方便 访问 而 已 。 





第 四 部 分 ”完美 世界 


一 一 设计 模式 混纺 
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命令 模式 + 贡 任 链 模 式 
工厂 方法 模式 + 寅 上 略 模式 
观察 者 模式 + 中 介 者 模式 





第 34 章 ”命令 模式 + 责任 链 模 式 
34.1 搬移 UNIX 的 命令 


在 操作 系统 的 世界 里 ， 有 两 大 阵营 一 直 在 PK 着 : *nix (包括 UNIX 
和 Linuxz) 和 Windows。 从 目前 的 统计 数据 来 看 ，*nix 在 应 用 服务 器 领域 
占据 相对 优势 ， 不 过 Windows 也 不 甘 示 弱 ， 国 内 某 些 小 型 银行 已 经 在 使 
用 PC Server〈 安 装 Windows 操 作 系 统 的 服务 器 ) 集群 来 进行 银行 业务 运 
算 ， 而 且 稳定 性 、 性 能 各 方面 的 效果 不 错 ; 而 在 个 人 桌面 方面 ， 
Windows 是 占 绝对 优势 的 ， 大 家 应 该 基本 上 都 在 用 这 个 操作 系统 ， 它 的 
诸多 优点 这 里 就 不 多 说 了， 我 们 今天 就 来 解决 一 个 习惯 问题 。 如 果 你 负 
责 过 UNIX 系 统 维护 ， 你 自己 的 笔记 本 又 是 windows 操 作 系统 的 话 ， 我 


页 
想 你 肯定 有 这 样 的 经 验 ， 如 图 34-1 所 示 。 





:\Documents and Sett ings “Admin istrator>1s 
在 提 局部 或 外 部 命令 ， 也 不 是 可 运行 的 程序 


:\Documents and Settings dministrator>ls 一 La 


'1s， 不 是 内 部 或 外 部 命令 ， 也 不 是 可 运行 的 程序 


或 批 处 理 文 件 。 


:\Documents and Settlings\nhdmin istrator>]1 
'11 不 是 内 部 或 外 部 命 全， 也 不 是 可 运行 的 程序 
或 批 处 理 文 件 。 


:Documents and SettinosNnhdministhator> 


图 34-1 时 常 犯 的 错误 





是 不 是 经 常 把 UNIX 上 的 命令 裔 到 Windows 系 统 了 ? 为 了 避免 这 种 
情况 发 生 ， 可 以 把 UNIX 上 的 命令 移植 到 Windows 上 ， 也 就 是 Windows 下 
的 shell 工 具 ， 有 很 多 类 似 的 工具 ， 比 如 cygwin、GUN Bash 等 ， 这 些 都 
是 非常 完美 的 工具 ， 我 们 今天 的 任务 就 是 自己 写 一 个 这 样 的 工具 。 怎 么 
写 呢 ? 我 们 学 了 这 么 多 的 模式 ， 当 然 要 融会 员 通 了 ， 可 以 使 用 命令 模 
式 、 责 任 链 模式 、 模 板 方法 模式 设计 一 个 方便 扩展 、 稳 定 的 工具 。 





我 们 先 说 说 UNIX 下 的 命令 ， 一 条 命令 分 为 命令 名 、 选 项 和 操作 
数 ， 例 如 命令 "ls-l/usr"， 其 中 ，1]s 是 命令 名 ，1 是 选项 ，/usr 是 操作 数 ， 后 
两 项 都 是 可 选项 ， 根 据 实际 情 况 而 定 。UNIX 命 令 一 定 遵守 以 下 几 个 规 
则 : 








。 命令 名 为 小 写字 母 。 


e 命令 名 、 选 项 、 操 作 数 之 间 以 空格 分 隔 ， 空 格 数量 不 受 限 制 。 


e 选项 之 间 可 以 组 合 使 用 ， 也 可 以 单独 拆 分 使 用 。 


e 选项 以 横 杠 〈-) 开头 。 


在 UNIX 世 界 中 ， 我 们 最 第 用 的 就 是 ls 这 个 命令 ， 它 用 于 显示 目录 或 
文件 信息 ， 下 面 我 们 先 来 看 看 这 个 命令 。 币 用 的 有 以 下 几 条 组 合 命令 : 


e ls: 简单 列 出 一 个 目录 下 的 文件 。 


e ls-1: 详细 列 出 目录 下 的 文件 。 


e ls-a: 列 出 目录 下 包含 的 隐藏 文件 ， 主 要 是 点 号 〈.) 开头 的 文 
fs 





e ls-s: 列 出 文件 的 大 小 。 





除 此 之 外 ， 还 有 一 些 非常 常用 的 组 合 命令 ， 如 "1s-la"、"ls-ls" 等 。1s 
命令 名 确定 了 了， 但 是 其 后 连接 的 选项 和 操作 数 是 不 确定 的 。 操 作 数 我 们 
不 用 关心 它 ， 每 个 命令 必然 有 一 个 操作 数 ， 大 没有 则 是 当前 的 目录 。 问 
题 的 关键 是 选项 ， 用 哪个 选项 以 及 什么 时 候 使 用 都 是 由 用 户 决 定 的 ， 也 
就 是 从 设计 上 考虑 。 设 计 者 需要 完全 解析 所 有 的 参数 ， 需 要 很 多 个 类 来 
处 理 如 此 多 的 和 选项， 客户 输 入 一 个 参数 ， 立 刻 返 回 一 个 结果 。 和 针对 一 个 


e 每 一 个 ls 命令 都 有 操作 数 ， 默 认 操 作 数 为 当前 目录 。 


e 选项 不 可 重复 ， 例 如 对 于 "ls-L-1-s"， 解 析出 的 选项 应 该 只 有 两 
个 : ] 选 项 和 s 选 项 。 


e 每 个 选项 返回 不 同 的 结果 ， 也 就 是 说 每 个 选项 应 该 由 不 同 的 业务 
逻辑 来 处 理 。 





e 为 提高 扩展 性 ，1s 命 令 族 内 的 运算 应 该 是 对 外 封 困 的 ， 减 少 外 办 
访问 ls 命令 族 内 部 细 市 的 可 能 性 。 


针对 一 个 命令 族 的 分 析 结 果 ， 我 们 可 以 使 用 什么 模式 ?责任 链 模 
式 ! 对 ， 只 要 把 一 个 参数 传递 到 链 首 ， 就 可 以 立刻 获得 一 个 结果 ， 中 间 
是 如 何 传递 的 以 及 由 哪个 逻辑 解析 都 不 需要 外 界 〈 高 层 ) 模块 关心 ， 该 
模块 的 类 图 如 图 34-2 所 示 。 
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+final Strng handleMessage(CommandVO vo) 
+void setNext(CommandName operator) 
+String getOperateParam() 
+String echo(CommandVO vo) 


I | 
EE 








负责 组 装 B 命 令 





所 有 命令 的 老 祖 宗 











区 革 
实现 ls -a 命 令 


实现 k 命 令 、 实现 k -I 命令 - 


图 34-2 命令 族 的 解析 类 图 


类 图 还 是 比较 清晰 的 ，UNIX 的 命令 有 上 百 个 ， 我 们 定义 一 个 
CommandName 抽 象 类 ， 所 有 的 命令 都 继承 于 该 类 ， 它 就 是 责任 链 模 式 
的 handler 类 ， 负 责 链 表 控制 ， 每 个 命令 族 都 有 一 个 独立 的 抽象 类 ， 因 为 

每 个 命令 族 都 有 其 独特 的 个 性 ， 比 如 ls 命令 和 df 命令 ， 其 后 可 加 的 参数 
是 不 一 样 的 ， 这 就 可 以 在 抽象 类 AbstractLS 中 定义 ， 而 且 它 还 有 标示 作 
用 ， 标 示 其 下 的 实现 类 都 是 实现 ls 命令 的 ， 只 是 命令 的 选项 不 同 ; 
Context 负 责 建立 一 条 命令 的 链表 ， 比 如 ls 命令 族 、df 命 令 族 等 ， 它 组 装 
出 一 个 处 理 一 个 命令 族 的 责任 链 ， 并 返回 首 节点 供 高 层 模块 调用 ， 这 是 
非常 典型 的 责任 链 模 式 。 








分 析 完 毕 一 个 具体 的 命令 族 ， 已 经 确定 可 以 采用 责任 链 模式 ， 我 们 
继续 往 下 分 析 。UNIX 命 令 非 常 多， 敬一 个 命令 返回 一 个 结果 ， 每 个 具 
体 的 命令 可 以 由 相关 的 命令 族 (也 就 是 责任 链 ) 来 解析 ， 但 是 如 此 多 的 
命令 还 是 需要 有 一 个 派发 的 角色 ， 输 入 一 个 命令 ,不管 后 台 谁 来 解析 ， 
返回 一 个 结果 束 成 ， 这 束 要 用 到 命令 和 模式。 命令 模 式 负责 协调 各 个 命令 
正确 地 传递 到 各 个 贡 任 链 的 首 节 点， 这 吏 是 它 的 任务 ， 其 类 图 如 图 34-3 
所 示 。 
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+String execute(CommandVO vo) 
#final List buildCham(Class abstractClass) 







LSCommand 
P= 
| | 












解析 命令 ， 并 调用 链 的 首 节 点 


命令 解析 的 责任 链 


图 34-3 命令 传递 类 图 


古 不 是 典型 的 命令 模式 类 图 ? 其 中 Chain 是 一 个 标示 符 ， 表 示 的 就 
古 我 们 上 面 分 析 的 贡 任 链 ， 每 一 个 具体 的 命令 负责 调用 贡 任 链 的 首届 
点 ， 获 得 返回 值 ， 结 束 命 令 的 执行 。 两 个 核心 模块 都 分 析 完 毕 了 ， 就 可 


以 把 类 图 融合 在 一 起 ， 完 整 的 类 图 如 图 34-4 所 示 。 
这 个 类 图 还 是 比较 简单 的 ， 我 们 来 看 一 下 各 个 类 的 职 贡 。 


© ClassUtils 





ClassUtils 是 工具 类 ， 其 主要 职 贡 是 根据 一 个 接口 、 父 类 查找 到 所 有 
的 子 类 。 在 不 考虑 效率 的 应 用 中 ， 使 用 该 类 可 以 布 来 非常 好 的 扩展 性 。 


e CommandVO 
CommandVO 是 命令 的 值 对 象 ， 它 把 一 个 命令 解析 为 命令 名 、 选 


项 、 操 作 数 ， 例 如 "ls-j/usr" 命 令 分 别 解析 为 getCommandName、 


getParam、getData 三 个 方法 的 返回 值 。 
e CommandEnum 


CommandEnum 是 枚 举 类 型 ， 是 主要 的 命令 配置 文件 。 为 什么 需要 
枚 举 类 型 ? 这 是 JDK 1.5 提 供 的 一 个 非常 好 的 功能 ， 我 们 在 程序 中 再 讲 
解 如 何 使 用 它 。 





所 有 的 分 析 都 已 经 完成 了 ， 我 们 来 看 看 程序 。 程 序 不 复杂 ， 看 看 类 
图 ， 应 该 先 写 命令 的 解释 ， 这 是 项 目的 核心 。 我 们 先 来 看 
CommandName 抽 象 类 ， 如 代码 清单 34-1 所 示 。 
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+String exec(Strmg _commandstr) 
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Class Utils 
+String execute(CommandVOQO vo) 


.…| #final List buildChain(Class abstractClass) 
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2 CommandName 
| 
+final Strng handle Message(CommandVO vo) 
+void setNext(CommandName _operator) 
+String getOperateParam!() 
+String echo(CommandVO vo) 


AbstractLS 













图 34-4 完整 类 图 


代码 清单 34-1 抽象 命令 名 类 


public abstract class CommandName { 
private CommandName nextOperator; 
public final String handleMessage(CommandVO vo)t{ 
// 处 理 结 
String result = "",; 
// 判 断 是 否 是 自己 处 理 的 参数 











if(vo.getParam().size() == 0 || vo.getParam( ) .contai 
result = this,echo(vo) ; 
}elset 
if(this.nextOperator !=null)t{ 
result = this.nextOperator.handleMes 
}elsef{ 


} 


return result,; 


} 

// 设 置 剩余 参数 由 谁 来 处 理 

public void setNext(CommandName _operator ){ 
this.nextOperator = _operator; 


} 

// 每 个 处 理 者 都 要 处 理 一 个 后 级 参数 

protected abstract String getOperateParam(); 
// 每 个 处 理 者 都 必须 实现 处 理 任务 

protected abstract String echo(CommandVO vo); 





result = "命令 无 法 执行 "; 


































































































很 简单 ， 就 是 责任 链 模 式 中 的 handler， 也 就 是 中 控 程 序 ， 控 制 一 个 
链 应 该 如 何 建立 。 我 们 再 来 看 3 个 ls 命令 族 ， 先 看 AbstractLS 抽 象 类 ， 如 
代码 清单 34-2 所 示 。 


代码 清单 34-2 抽象 ls 命令 


public abstract class AbstractLS extends CommandName{ 
// 默 认 参 数 
public final static String DEFAULT_PARAM = ""， 
// 参 数 a 
public final static String A_PARAM ="a"; 
// 参 数 1 
public final static String L_PARAM = "1"，; 








很 惊讶 ， 是 吗 ? 怎么 是 个 空 的 抽象 类 ? 是 的 ， 确 实 是 一 个 空 类 ， 只 


定义 了 3 个 参数 名 称 ， 它 有 两 个 职责 : 


e 标记 ls 命令 族 。 


个 性 化 处 理 。 





因为 现在 还 没有 思考 清楚 ls 有 什么 个 性 (可 以 把 命令 的 选项 也 认为 
是 其 个 性 化 数据 》， 所 以 先 写 个 空 类 放 在 这 里 ， 以 后 想 清 楚 了 再 填写 上 
去 ， 留 下 一 些 可 扩展 的 类 也 许 会 给 未 来 带 来 不 可 估量 的 优点 。 





我 们 再 来 看 1s 不 带 任 何 参 数 的 命令 处 理 ， 如 代码 清单 34-3 所 示 。 


代码 清单 34-3 ls 命令 


public class LS extends AbstractLS { 
// 最 简单 的 ls 命令 
protected String echo(CommandVO vo) { 
return FileManager.1ls(vo.formatData( )); 


} 

// 参 数 为 空 

protected String getoperateParam( ) { 
return Super ,DEFAULT_PARAM ， 

} 


太 简 单 了 ， 首 先 定义 了 自己 能 处 理 什么 样 的 参数 ， 即 只 能 处 理 不 带 
参数 的 ls 命令 ，getOperateParam 返 回 一 个 长 度 为 零 的 字符 串 ， 就 是 说 该 
类 作为 链 上 的 一 个 节点 ， 只 处 理 没有 参数 的 ls 命令 。echo 方 法 是 执行 ]s 
命令 ， 通 过 调用 操作 系统 相关 的 命令 返回 结果 。 我 们 再 来 看 ls -] 命 令 ， 
如 代码 清单 34-4 所 示 。 


代码 清单 34-4 1s-] 命 令 


public class LS_L extends AbstractLS { 
protected String echo(CommandVO vo) { 
return FileManager.1s_1l(vo.formatData( )); 
} 
//1 选 项 
protected String getOperateParam() { 
return super.L_PARAM; 
} 


该 类 只 处 理 选项 为 "1" 的 命令 ， 也 非常 简单 。1s-a 命 令 的 处 理 与 此 类 
似 ， 如 代码 清单 34-5 所 示 。 


代码 清单 34-5 ls-a 命 令 


public class LS A extends AbstractLS { 
//ls -a 命令 
protected String echo(CommandVO vo) { 
return FileManager.1s_a(vo.formatData( )); 


protected String getOperateParam() { 
return super.A PARAM; 
} 


这 3 个 实现 类 都 关联 到 了 FileManager， 这 个 类 有 什么 用 呢 ? 它 是 负 
责 与 操作 系统 交互 的 。 要 把 UNIX 的 命令 迁移 到 Windows 上 运行 ， 就 需 
要 调用 Windows 的 低层 函数 ， 实 现 起 来 较 复杂 ， 而 且 和 我 们 本 章 要 讲 的 
内 容 没有 太 大 关系 ， 所 以 这 里 采用 示例 性 代码 代 蔡 ， 如 代码 清单 34-6 所 


不 。 





代码 清单 34-6 文件 管理 类 


public class FileManager { 
//ls 命 令 
public static String ls(String path)t{ 


return "filei\nfile2\nfile3\nfile4"; 

//1SsS -1 命令 

public static String ls_1l(String path)t{ 
String str = "drw-rw-rw root system 1024 2009-8-20 1 
str = str + "drw-rw-rw root System 1024 2009-8-20 10 
str = str + "drw-rw-rw root System 1024 2009-8-20 10 
return str; 

//ls -a 命令 

public static String ls_a(String path){ 


String str = ".\n..\nfile1i\nfile2\nfile3"; 
return str; 


以 上 都 是 比较 简单 的 方法 ， 大 家 有 兴趣 可 以 自己 实现 一 下 ， 以 下 提 
供 3 种 思路 : 


e 通过 java.io.File 类 上 自己 封装 出 类 似 UNIX 的 返回 格式 。 


e 通过 java.lang.Runtime 类 的 exec 方 法 执行 dos 的 dir 命 令 ， 产 生 类 似 
的 ls 结果 。 


e 通过 JNI (Java Native Interface) 来 调用 与 操作 系统 有 关 的 动态 链 
接 库 ， 当 然 前 提 是 需要 目 己 写 一 个 动态 链接 库 文 件 。 








3 个 具体 的 命令 都 已 经 解析 完毕 ， 我 们 再 来 看 看 如 何 建 立 一 条 处 理 
链 ， 由 于 建 链 的 任务 已 经 移植 到 抽象 命令 类 ， 我 们 就 先 来 看 抽象 类 
Command， 如 代码 清单 34-7 所 示 。 


代码 清单 34-7 抽象 命令 


public abstract class Command { 
public abstract String execute(CommandVO vo); 
// 建 并 链表 
protected final List<? extends CommandName> buildchain(Class 
// 取 出 所 有 的 命令 名 下 的 子 类 
List<Class> classes = ClassUtils.getSonClass(abstrac 
// 存 放 命 令 的 实例 ， 并 建立 链表 关系 
List<CommandName> commandNameList = new ArrayList<Co 
for(Class c:classes)t{ 
CommandName commandName =null; 
try { 











// 产 生 实例 

commandName = (CommandName)Class.for 
} catch (EXCeptaon e){ 

// TODO 异常 处 理 
} 


// 建 立 链表 

if(commandNameList.size()>0){ 
commandNameList.get(commandNameList. 

} 


commandNameList ,add(CcommandName ) ， 























} 


return commandNameList ， 


一 


Command 抽 象 类 有 两 个 作用 : 一 是 定义 命令 的 执行 方法 ， 二 是 负责 
命令 族 《〈 责 任 链 ) 的 建立 。 其 中 buildChain 方 法 负责 建立 一 个 责任 链 ， 
它 通 过 接收 一 个 抽象 的 命令 族 类 束 可 以 建立 一 条 命令 解析 链 ， 如 传递 
AbstarctLS 类 就 可 以 建立 一 条 解析 ]s 命 令 族 的 贡 任 链 ， 请 读者 注意 如 下 
这 人 句 代 码 : 


commandName = (CommandName)Class.forName(c.getName()).newInstance 








企 一 个 衣 历 中 ， 关 中 的 每 个 元 素 都 是 一 个 类 名 ， 然 后 根据 类 名 产生 
一 个 实例 ， 它 会 抛 出 异常 ， 例 如 类 文件 不 存在 、 初 始 化 失败 等 ， 读 者 在 
设计 时 要 实现 该 部 分 的 异常 。 我 们 再 来 想 一 下 ， 每 个 实现 类 的 类 名 是 如 








何 取得 的 呢 ? 看 下 面 这 句 代 码 : 


List<Class> classes = ClassUtils.getSonClass(abstractClass ) ; 





根据 一 个 父 类 取得 所 有 子 类 ， 是 一 个 非常 好 的 工具 类 ， 其 实现 如 代 
码 清单 34-8 所 示 。 








代码 清单 34-8 根据 父 类 获得 子 类 


public class ClassUtils { 
// 根 据 父 类 查找 到 所 有 的 子 类 ， 默 认 情 况 是 子 类 和 父 类 都 在 同一 个 包 名 下 
public static List<Class> getSonClass(Class fatherClass)t{ 
// 定 义 一 个 返回 值 
List<Class> returnClassList = new ArrayList<Class>(); 

















// 获 得 包 名 称 

String packageName = fatherClass ,getPackage().getName( ) 
// 获 得 包 中 的 所 有 类 

List<Class> packClasses = getClasses(packageName); 

// 判 断 是 否 是 子 类 


for(Class c:packClasses)t 
if(fatherClass.isAssignableFrom(c) && !fatherClass 
returnClassList.add(c); 
} 
} 


return returnClassList,; 


} 
// 从 一 个 包 中 查找 出 所 有 的 类 ， 在 jar 包 中 不 能 查找 
private static List<Class> getClasses(String packageName) { 
ClassLoader classLoader = Thread.currentThread ( ) 
.getContextClassLoader(); 
String path = packageName.replace('.', '/'); 
Enumeration<URL> resources = null; 
try { 
resources = classLoader .getResources(path); 
} catch (IOException e) { 
// TODO Auto-generated catch block 
e.printStackTrace( ); 





List<File> dirs = new ArrayList<File>(); 
while (resources.hasMoreElements()) { 
URL resource = resources.nextElement(); 
dirs.add(new File(resource.getFile())); 


ArrayList<Class> classes = new ArrayList<Class>(); 
for (File directory : dirs) { 
classes.addAll(findClasses(directory, packageName) 


return classes,; 
} 
private static List<Class> findClasses(File directory, Strin 
List<Class> classes = new ArrayList<Class>(); 
If (!'directory.exists()) { 
return classes,; 


File[] files = directory.1listFiles(); 
for (File file : files) { 
if (file.isDirectory()) { 
assert !file.getName().contains("."); 
classes.addAll(findClasses(file, packageName + ". 
} else if (file.getName().endswith(".class")) { 
try { 
classes.add(Class.forName(packageName + '.' + file.getNanm 
} catch (ClassNotFoundException e) { 
e.printStackTrace( ); 
} 


; 


return classes,; 





这 个 类 请 大 家 谨慎 使 用 ， 在 核心 的 应 用 中 尽量 不 要 使 用 该 工具 ， 它 
会 严重 影响 性 能 。 


再 来 看 LSCommand 类 的 实现 ， 如 代码 清单 34-9 所 示 。 


代码 清单 34-9 具体 的 ls 命令 


public class LSCommand extends Command{ 
public String execute(CommandVO vo)t{ 
// 返 回 链表 的 首 节点 
CommandName firstNode = Super.buildCchain(AbstractLS ， 
return firstNode.handleMessage(vo); 





很 简单 的 方法 ， 先 建立 一 个 命令 族 的 责任 链 ， 然 后 找到 首 节点 调 
用 。 在 该 类 中 我 们 使 用 CommandVO 类 ， 它 是 一 个 封装 对 象 ， 其 代码 如 
代码 清单 34-10 所 示 。 


代码 清单 34-10 命令 对 象 


public class CommandVo { 
// 定 义 参数 名 与 参数 的 分 隔 符号 ,一般 是 空格 
public final static String DIVIDE_FLAG =" "; 
// 定 义 参数 前 的 符号 ，Unix 一 般 是 - ,如 1s -1a 
public final static String PREFIX="-"，; 
// 命 令 名 ， 如 1s、 du 





private String commandName = ""， 

// 参 数列 表 

private ArrayList<String> paramList = new ArrayList<String>( 
// 操 作 数 列表 


private ArrayList<String> dataList = new ArrayList<String>() 
// 通 过 构造 函数 传递 进来 命令 
public CommandVO(String commandStr){ 
// 和 常规 判断 
if(commandStr != null && commandStr ,Jength() !=0){ 
// 根 据 分 隔 符号 拆 分 出 执行 符号 
String[] complexStr = commandStr.split(Comma 
// 第 一 个 参数 是 执行 符号 
this.commandName = complexStr[0]; 
// 把 参数 放 到 List 中 
for(int i=1;i<complexStr.length;i++){ 
String str = complexStr[i]; 
// 包 含 前 缀 符号 ， 认 为 是 参数 
if(str,.indexof(CommandVo ,PREFIX)==O0) 
this.paramList.add(str.replace 
(CommandVO .PREFIX, "").trim()); 
}elsef{ 


} 





this.dataList.add(str.trim() 


}elsef{ 
// 传 递 的 命令 错误 
System.out.println(" 命 令 解析 失败 ， 必 须 传递 一 个 命 4 


} 

// 得 到 命令 名 

public String getCommandName( ){ 
return this.commandName; 





} 
// 获 得 参数 
public ArrayList<String> getParam(){ 
// 为 了 方便 处 理 空 参 数 
if(this.paramList.size() ==0){ 
this.paramList.add(""); 


























} 

return new ArrayList(new HashSet(this.paramList)); 
} 
// 获 得 操作 数 


public ArrayList<String> getData(){ 
return this.datalList; 
} 


CommandVO 解 析 一 个 命令 ， 规 定 一 个 命令 必须 有 3 项 : 命令 名 、 选 
项 、 操 作 数 。 如 果 没 有 呢 ? 那 就 以 长 上 度 为 零 的 字符 串 代 蔡 ， 通 过 这 样 的 
一 个 约定 可 以 大 大 降低 命令 解析 的 开发 工作 。 注 意 getParam 参 数 中 的 返 
回 值 : 


new ArrayList(new HashSet(this.paramList)); 


为 什么 要 这 么 处 理 ? HashSet 具 有 值 唯 一 的 优点 ， 这 样 处 理 就 是 为 
了 避免 出 现 两 个 相同 的 参数 ， 比 如 对 于 "ls-l-l-s" 这 样 的 命令 ， 通 过 
getParam 返 回 的 参数 是 几 个 呢 ? 回答 是 两 个 : 1 选项 和 s 选 项 。 





我 们 再 来 看 mvoker 类 ， 它 是 负 贡 命令 分 发 的 类 ， 如 代码 清单 34-11 
所 示 。 


代码 清单 34-11 命令 分 发 


public class Invoker { 
// 执 行 命令 
public String exec(String _commandStr)t{ 
// 定 义 返回 值 
String eu = "") 
// 首 先 解析 命令 
CommandVO vo = new CommandVo(_commandStr ) ， 
// 检 查 是 否 文 持 该 命令 
if(CommandEnum.getNames().contains(vo.getCommandName 
// 产 生命 令 对 象 
String className = CommandEnum.valueOf (vo.getc 
Command command; 
try { 
command = (Command)Class.forName(className 
result = command.execute(vo); 
}catch(Exception e)t{ 
// TODO 异常 处 理 
































} 
}elsef 
result = "无 法 执行 命令 ， 请 检查 命令 格式 "， 








return result,; 


实现 也 是 比较 简单 的 ， 从 CommandEnum 中 获得 命令 与 命令 类 的 配 
置信 息 ， 然 后 建立 一 个 命令 实例 ， 调 用 其 execute 方 法 ， 完 成 命令 的 执行 
操作 。CommandEnum 类 是 一 个 枚 举 类 型 ， 如 代码 清单 34-12 所 示 。 


代码 清单 34-12 命令 配置 对 象 


public enum CommandEnum { 
ls("com.cbf41life.common.command.LSCommand"); 
private String value = ""; 
// 定 义 构造 函数 ， 目的 是 Data(value ) 类 型 的 相 匹 配 
private CommandEnum(String value)t{ 
this.value = Value， 





} 
public String getValue(){ 
return this.value; 


} 
// 返 回 所 有 的 enum 对 象 





public static List<String> getNames(){ 
CommandEnum[] commandEnum = CommandEnum.values( ); 
List<String> names = new ArrayList<String>(); 
for(CommandEnum c:commandEnum){ 
names.add(c.name( )); 
} 


return names; 





为 什么 要 用 枚 举 类 型 ? 用 一 个 接口 来 管理 也 是 很 容易 实现 的 。 注 意 
CommandEnum 中 的 构造 函数 CommandEnum(String value) 和 getValue 
类 ， 没 有 新 建 一 个 Enum 对 象 ， 但 是 可 以 直接 使 用 
CommandEnum.ls.getValue 方 法 获得 值 ， 这 就 是 Enum 类 型 的 独特 地 方 。 
再 看 下 面 : 





ls("com.cbf41life.common.command.LSCommand"); 

是 不 是 很 特别 ? 是 的 ， 枚 举 的 基本 功能 就 是 定义 默认 可 选 值 ， 但 是 
Java 中 的 枚 举 功 能 义 增强 了 很 多 ， 可 以 添加 方法 和 属性 ， 基 本 上 就 是 一 
个 特殊 的 类 。 知 要 详细 了 解 Enum， 读 者 可 以 翻阅 一 下 相关 语法 书 。 








现在 剩 下 的 工作 就 是 写 一 个 Client 类 ， 然 后 看 看 运行 情况 如 何 ， 如 
代码 清单 34-13 所 示 。 


代码 清单 34-13 场景 类 


public class Client { 
public static void main(String[] args) throws IOException { 
Invoker invoker = new Invoker(); 
while(true)t 
//UNIX 下 的 默认 提示 符号 
System.out.print("#"); 





// 捕 获 输出 

String input = (new BufferedReader(new Input 

// 输 入 quit 或 exit 则 退出 

if(input.equals("quit") || input.equals("exi 
return; 

} 


System.out.println(invoker.exec(input)); 





Client 也 很 简单 ， 通 过 一 个 while 循 环 允 许 使 用 者 持续 输入 ， 然 后 打 
印 出 返回 值 ， 运 行 结 末 如 下 : 


#1]s 


filel 


file2 


file3 


file4 


#l]s -|] 


drw-rw-rw 


drw-rw-rw 


drw-rw-rw 


#l]s -a 


filel 


file2 


system 1024 2009-8-20 10:23 filel 
system 1024 2009-8-20 10:23 file2 


system 1024 2009-8-20 10:23 file3 


file3 


#quit 


我 们 已 经 实现 了 在 Windows 下 操作 UNIX 命 令 的 功能 ， 但 是 仅仅 一 
个 ls 命令 族 是 不 够 的 ， 我 们 要 扩展 ， 把 一 百 多 个 命令 都 扩展 出 来 ， 怎 么 
扩展 呢 ? 现在 增加 一 个 df 命令 族 ， 显 示 磁 盘 的 大 小 ， 只 要 增加 类 图 就 
成 ， 如 图 34-5 所 示 。 


















Invoker 


string csco(Sring_commandStr.) 


一 








+String execue(CommandVoO vo) 
#Einal List buildcham (Class abstractClass) 


CommandVO LSCommand DFCommand 





CommandName 


= 
+final Strng handleMessage(CommandVO vo) 
+void setNext(CommandName_operator) 
+String getOperateParam() 

+String echo(CommandVO vo) 





图 34-5 扩展 df 命令 后 的 类 图 


仅仅 增加 了 钥 框 的 部 分 ， 也 就 是 增加 DFCommand、AbstractDF 以 及 
实现 类 就 可 以 完成 扩展 功能 。 先 看 AbstractDF 代 码 ， 如 代码 清单 34-14 所 


帮 \。 


代码 清单 34-14 df 命令 的 抽象 类 


public abstract class AbstractDF extends CommandName { 
// 默 认 参 数 
public final static String DEFAULT_PARAM = ”"”， 
// 参 数 k 
public final static String K_PARAM = "k"，; 
// 参 数 g 
public final static String G_ PARAM = "g"，; 











与 前 面 一 样 的 功能 ， 定 义 选项 名 称 。 接 下 来 是 三 个 实现 类 ， 都 非常 
简单 ， 如 代码 清单 34-15 所 示 。 


代码 清单 34-15 df 命令 的 具体 实现 类 


public class DF extends AbstractDF{ 
// 定 义 一 下 自己 能 处 理 什么 参数 
protected String getoperateParam( ) { 
return Super ,DEFAULT_PARAM ， 



































/ 命 ~ 令 处 理 
ee String echo(CommandVO vo) { 
return DiskManager .df(); 
} 


} 
public class DF_K extends AbstractDF{ 
// 定 义 一 下 自己 能 处 理 什么 参数 
protected String getOperateParam() { 
return super.K_PARAM; 
} 












































// 命 令 处 理 

protected String echo(CommandVO vo) { 
return DiskManager.df_k(); 

} 


public class DF_G extends AbstractDF{ 
// 定 义 一 下 自己 能 处 理 什么 参数 
protected String getoperateParam( ) { 
return Super.G_PARAM ; 









































} 

// 命 令 处 理 

protected String echo(CommandVO vo) { 
return DiskManager.df_g(); 

} 


ww 


每 个 选项 的 实现 类 都 定义 了 自己 能 解析 什么 命令 ， 然 后 通过 echo 方 
法 返回 执行 结果 。 在 三 个 实现 类 中 都 与 DiskManager 类 有 关联 关系 ， 该 
类 负责 与 操作 系统 有 关 的 功能 ， 是 必须 要 实现 的 ， 其 示例 代码 如 代码 清 
单 34-16 所 示 。 








代码 清单 34-16 磁盘 管理 


public class DiskManager { 
// 默 认 的 计算 大 小 
public static String df(){ 
return "/\t10485760\Nn/usr\t104857600\n/home\t1048576 


} 
// 按 照 kb 来 计算 
public static String df_k()t{ 
return "/\t10240\n/usr\t102400\n/home\tt10240000\n"; 





} 
// 按 照 gb 计 算 
public static String df gf(){ 
return "/\t10\n/usr\t100\n/home\tt10000\n"; 
} 





以 上 为 示例 代码 ， 知 要 实际 计算 磁盘 大 小 ， 可 以 使 用 JNI 的 方式 或 


者 执行 操作 系统 的 命令 的 方式 获得 ， 特 别 是 JDK 1.6 提 供 了 获得 一 个 root 
目录 大 小 的 方法 。 


然后 再 增加 一 个 DFCommand 命 令 ， 人 负责 执行 命令 ， 如 代码 清单 34- 


17 所 示 。 


代码 清单 34-17 可 执行 的 df 命令 


public class DFCommand extends Command { 
public String execute(CommandVO vo) { 
return super.buildchain(AbstractDF.class).get(0).han 
} 


最 后 一 步 ， 修 改 一 下 CommandEnum 配 置 ， 增 加 一 个 枚 举 项 ， 如 代 
码 清单 34-18 所 示 。 


代码 清单 34-18 增加 后 的 枚 举 项 


public enum CommandEnum { 
ls("com.cbf41life.common.command.LSCommand"), 
df("com.cbf41life.common.command.DFCommand"); 
private String value = ""， 
// 定 义 构造 函数 ， 目 的 是 Data(value ) 类 型 的 相 匹配 
private CommandEnum(String value)t{ 
this.value = Value， 











} 
public String getValue(){ 
return this.value; 


} 

// 返 回 所 有 的 enum 对 象 

public static List<String> getNames(){ 
CommandEnum[] commandEnum = CommandEnum.values( ); 
List<String> names = new ArrayList<String>(); 
for(CommandEnum c:commandEnum){ 

names.add(c.name( )); 

} 





return names ; 


运行 结果 如 下 所 示 : 
#1]s 

filel 

file2 

file3 

file4 

#df 

/ 10485760 

/usr 104857600 
/home 1048576000 
#df -k 

/ 10240 

/usr 102400 
/home t10240000 
#df -g 

/ 10 

/usr 100 


/lhome t10000 


仅仅 增加 类 就 完成 了 变更 ， 这 才 是 我 们 要 的 结果 : 对 修改 关闭 ， 对 
扩展 开放 。 


342 规 纺 小 结 





在 这 里 的 例子 中 用 到 了 以 下 模式 。 


e 责任 链 模式 





负责 对 命令 的 参数 进行 解析 ， 而 且 所 有 的 扩展 都 是 增加 链 数量 和 节 
扩 ， 不 涉及 原 有 的 代码 变更 。 


负责 命令 的 分 发 ， 把 适当 的 命令 分 发 到 指定 的 链 上 。 

e 模板 方法 模式 

在 Command 类 以 及 子 类 中 ，buildChain 方 法 是 模板 方法 ， 只 是 没有 
基本 方法 而 已 ;在 责任 链 模 式 的 CommandName 类 中 ， 用 了 一 个 典型 的 


模板 方法 handlerMessage， 它 调用 了 基本 方法 ， 基 本 方法 由 各 个 实现 类 
实现 ， 非 常 有 利于 扩展 。 





e 友 代 天 模式 





在 for 循 环 中 我 们 多 次 用 到 类 似 for(Class c:classes) 的 结构 ， 是 谁 来 支 
撑 该 方法 运行 ? 当然 是 欠 代 器 模式 ， 只 是 JDK 已 经 把 它 融 入 到 了 API 


中 ， 更 方便 使 用 了 。 


可 能 读者 已 经 注意 到 了 ，"ls-l-a" 这 样 的 组 合 选项 还 没有 处 理 。 确 实 
没有 处 理 ， 以 下 提供 两 个 思路 来 处 理 。 


e 独立 处 理 


"1s-]-a" 等 同 于 "ls-l]a"， 也 等 同 于 "ls-al" 命 令 ， 可 以 把 "ls-la" 中 的 选 
项 "la" 作 为 一 个 参数 来 进行 处 理 ， 扩 展 一 个 类 束 可 以 了 。 该 方法 的 缺点 
是 类 膨胀 得 太 大 ， 但 是 简单 。 


泥 品 合 处 理 





修正 命令 族 处 理 链 ， 每 个 命令 处 理 节点 运行 完毕 后 ， 继 续 由 后 续 节 
点 处 理 ， 最 终 由 Command 类 组 装 结 果 ， 根 据 每 个 节点 的 处 理 结果 ， 组 合 
后 生成 完整 的 返回 信息 ， 如 "ls-l-a" 就 应 该 是 LS_L 类 与 LS_A 类 两 者 返回 
值 组 装 的 结果 ， 当 然 链 上 的 节点 返回 值 就 要 放 在 Collection 类 型 中 了 。 











该 框架 还 有 一 个 名 称 ， 叫 做 命令 链 《〈Chain of Command) 模式 ， 具 
体 来 说 吏 是 命令 模式 作为 责任 链 模式 的 排头 兵 ， 由 命令 模式 分 及 有 具体 的 
消息 到 员 任 链 模式 。 对 于 该 框 染 ， 读 者 可 以 继续 扩展 下 去 。 当 然 ， 上 面 
的 程序 还 可 以 优化 ， 优 化 的 结果 就 是 Command 类 纵 为 一 个 类 ， 通 过 
CommandEnum 配 置 文件 类 传递 命令 ， 这 比较 容易 实现 ， 读 者 可 以 目 行 








设计 。 


第 35 半 工厂 方法 模式 + 策略 模式 


35.1 迷你 版 的 交易 系统 


大 家 可 能 对 银行 的 交易 系统 充满 化 藤 之 情 ， 一 听 资 是 银行 的 工人 
员 ， 立 马 想当然 地 认为 这 是 个 很 厉害 的 人 物 ， 那 我 们 今天 就 来 对 银行 的 
交易 系统 做 一 个 初步 探讨 。 国 内 一 家 大 型 集团 (全 球 500 强 之 一 ) 计划 
建立 全 国 “ 一 卡通 ”计划 ， 每 个 员工 配备 一 张 IC 卡 ， 该 卡 基本 上 就 是 万 能 
的 ， 门 禁 系 统 用 它 ， 办 公 系 统 用 它 ， 你 想 打 开 自 己 的 邮箱 ， 没 有 它 就 月 
想 了 ， 它 还 可 以 用 来 进行 消费 ， 比 如 到 食 特 吃饭 ， 到 园区 内 的 商店 消 
费 ， 甚 至 洗 深 、 理 发 、 借 书 、 买 书 等 都 可 以 用 它 ， 只 要 这 张 卡 内 有 余 
额 ， 在 集团 内 部 就 是 一 张 借 记 卡 《当然 还 有 一 些 内 部 的 补助 通过 该 卡 发 
放 ) 。 我 们 要 讲解 的 就 是 “一 卡通 ”项 目 联 机 交易 子 系统 ， 类 似 于 银行 的 
交易 系统 ， 可 以 说 它 是 交易 系统 的 mini 版 吧 。 

















该 项 目 具 有 一 定 的 挑战 性 ， 集 团 公司 的 架构 分 为 三 层 : 总 部 、 省 级 
分 部 、 市 级 机 构 ， 业 务 要 求 是 “一 卡通 ”推广 到 全 国 ， 一 名 员工 从 北京 出 
差 到 了 上 海 ， 赁 一 卡通 能 在 北京 做 的 事情 在 上 海 同 样 能 完成 。 对 于 联机 
交易 子 项 目 ， 异 地 分 支 机 构 与 总 部 之 间 的 通信 采用 了 MQ (Message 
Queue， 消 息 队 列 ) 传递 消息 ， 也 就 是 我 们 观察 者 模式 的 BOSS 版 ， 与 目 
前 的 通过 POS 机 刷 信 用 卡 基 本 上 是 一 个 道理 。 








联机 交易 子 系统 有 一 个 非常 重要 的 子 模块 (Module) 扣 球 子 模 
块 。 这 个 模块 太 重 要 了 ! 从 业务 上 来 说 ， 扣 球 失 败 就 代表 着 所 有 的 商业 
交易 关闭 ， 这 是 不 允许 发 生 的 ; 从 技术 上 来 说 ， 扣 球 的 异 第 处 理 、 事 务 
处 理 、 重 棒 性 都 是 不 容 忽视 的 ， 特 别 是 饭 点 时 间 ， 并 发 量 是 很 恐怖 的 ， 
这 对 架构 师 提出 了 很 蜗 的 要 求 。 











我 们 详细 分 析 一 下 扣 球 子 模 块 ， 每 个 员工 部 有 一 张 IC 卡 ， 他 的 IC 卡 
上 有 以 下 两 种 金额 。 


是 指 员 工 不 能 提现 的 金额 ， 这 部 分 金额 只 能 用 来 特定 消 
日 第 必需 的 消费 ， 例 如 食 答 内 吃饭 、 理 发 、 健 身 等 活动 。 


目 由 金额 是 可 以 提现 的 ， 当 然 也 可 以 用 于 消费 。 每 个 月 初 ， 总 部 都 
会 为 每 个 员工 的 IC 卡 中 打 入 固定 数量 的 金额 ， 然 后 提倡 大 家 在 集团 内 的 
商店 消费 。 








在 实际 的 系统 开 及 中 ， 架 构 设 计 采 用 的 是 一 张 IC 卡 绑 定 两 个 账户 : 
固定 账 尸 和 上 自由 账号 ， 本 书 为 了 简化 描述 ， 还 是 使 用 固定 金额 和 目 由 金 
颌 的 概 仿 。 既 然 有 消费 ， 系 统 肯定 有 扣 球 处 理 ， 系 统 内 有 两 套 扣 球 规 
则 。 


e 扣 球 策略 一 


该 类 型 的 扣 球 会 对 IC 卡 上 的 两 个 金额 产生 影响 ， 计 算 公 式 如 下 : 


IC 卡 固 定 余额 =IC 卡 现 有 固定 余额 -交易 金额 /2 


IC 卡 上 自由 余额 =IC 卡 现 有 目 由 金额 -交易 金额 /2 


也 惑 是 说 ， 该 类 型 的 消费 分 别 在 固定 金额 和 目 由 金额 上 各 扣除 一 
半 。 它 适用 于 固定 消费 场景 例如 吃饭 、 理 发 等 情况 下 的 扣 款 ， 这 么 做 是 
为 了 防止 乱 请 客 ， 你 请 别人 吃饭 时 目 己 也 要 出 一 半 。 





e 扣 天 策略 二 


全 部 从 目 由 金额 上 扣除 ， 由 于 集团 内 的 各 种 消 宽 、 服 务 非 常 齐全 ， 
而 且 比 市 面 价格 稍 低 ， 员 工 还 是 很 乐意 到 这 里 消费 的 ， 而 且 很 多 员工 本 
号 就 住 在 集团 附近 ， 基 本 上 惑 是 “公司 即 家 ， 家 即 公司 ”。 














今天 要 讲 的 重点 就 是 这 两 种 消费 的 扣 亚 策略 该 怎样 设计 ? 要 知道 这 
种 联机 交易， 日 后 允许 大 规模 变更 的 可 能 性 基本 上 是 零 ， 所 以 系统 设计 
的 时 候 要 做 到 可 拆卸 (Pluggable) ， 避 免 日 后 维护 的 大 量 开 文 。 














很 明显 ， 这 是 一 个 策略 模式 的 实际 应 用 ， 但 是 你 还 记得 策略 模式 是 
有 缺陷 的 吗 ? 它 的 具体 策略 必须 暴露 出 去 ， 而 且 还 要 由 上 层 模 块 初始 
化 ， 这 不 合适 ， 与 迪 米 特 法 则 有 冲突 ， 高 层次 模块 对 低层 次 的 模块 应 该 











仅仅 处 在 “接触 ?的 层次 上 ， 而 不 应 该 是 “ 斐 合 ” 的 关系 ， 人 否则 ， 维 护 的 工 
作 量 就 会 非 第 大 。 问 题 提出 了 ， 那 我 们 就 应 该 想 办 法 来 修改 这 个 缺陷 ， 
正好 工厂 方法 模式 可 以 帮 我 们 产生 指定 的 对 象 ， 但 是 问题 又 来 了 ， 工 三 
方法 模式 要 指定 一 个 类 ， 它 才能 产生 对 象 ， 怎 么 办 ?引入 一 个 配置 文件 
进行 映射 ， 避 免 系统 僵化 情况 的 发 生 ， 我 们 以 枚 举 类 完成 该 任务 。 








还 有 一 个 问题 ， 一 个 交易 的 扣 球 模式 是 固定 的 ， 根 据 其 交易 编写 而 
定 ， 那 我 们 怎样 把 交易 编写 与 扣 球 集 略 对 应 起 来 呢 ? 采 用 状态 模式 或 贡 
任 链 模式 都 可 以 ， 如 果 采 用 状态 则 认为 交易 编号 就 是 一 个 交易 对 象 的 状 
态 ， 对 于 一 笔 确定 的 交易 《一 个 已 经 生成 了 的 对 象 ) ， 它 的 状态 不 会 从 
一 个 状态 过 小 到 夯 一 个 状态 ， 也 惑 是 说 它 的 状态 只 有 一 个 ， 执 行 完 毕 后 
即 结束 ， 不 存在 多 状态 的 问题 ， 如 果 采 用 贡 任 链 模式 ， 则 可 以 用 交易 编 
码 作 为 链 中 的 判断 依据 ， 由 每 个 执行 节操 进行 判断 ， 返 回 相应 的 扣 球 模 
式 。 但 是 在 实际 中 ， 采 用 了 关系 型 数据 库存 储 扣 球 规则 与 交易 编码 的 对 
应 关系 ， 为 了 简化 该 部 分 的 讲义 ， 我 们 在 下 面 的 设计 中 使 用 了 条 件 判 断 
语句 来 代 蔡 。 











还 有 ， 这 么 复杂 的 扣 区 模块 总 要 进行 一 个 封 疾 吧 ， 不 能 让 上 层 的 业 
务 模块 直接 深入 到 模块 的 内 部 ， 于 是 门面 模式 又 摆 在 了 眼前 。 
分 析 完 毕 ， 我 们 要 移 画 出 类 图 ， 做 设计 要 遵循 这 样 一 个 原则 : 先 选 


最 简单 的 业务 ， 然 后 画 出 类 图 。 那 我 们 先 定义 交易 中 用 到 的 两 个 类 : IC 
卡 类 和 交易 类 ， 如 图 35-1 所 示 。 





-String cardNo() 


-mt steadyMoney() 
-Int freeMoney() 


+getter/settr cardNo() 
+getter/settr steadyMoney() 
+getter/settr freeMoney() 





交易 信息 : 


和 = 自 - a 
IC 卡 信息 : stradeNO 交易 编码 


steadyMoney 固定 金额 


amount 交易 金额 
freeMoney 目 由 金额 





图 35-1 IC 卡 类 和 交易 类 


每 个 IC 卡 有 三 个 属性 ， 分 别 是 IC 卡号 码 、 固 定金 额 、 自 由 金额 ， 


后 通过 gettersetter 方 法 来 访问 ， 如 代码 清单 35-1 所 示 。 


代码 清单 35-1 IC 卡 类 


public class Card { 
//IC 卡 号 码 
private String cardNo=""; 
// 卡 内 的 固定 交易 金额 
private int steadyMoney =0; 
// 卡 内 自由 交易 金额 
private int freeMoney =0 
//getter/setter 方 法 
public String getCardNo() { 

return cardNo; 











public void setCardNo(String cardNo) { 
this.cardNo = cardNo; 


} 
public int getSteadyMoney() { 








然 


4 


return SteadyMoney ; 


} 
public void setSteadyMoney(int steadyMoney) { 
this.steadyMoney = steadyMoney; 


} 
public int getFreeMoney() { 
return freeMoney ; 


} 

public void setFreeMoney(int freeMoney) { 
this.freeMoney = freeMoney; 

} 


细心 的 读者 可 能 注意 到 ， 人 金额 怎么 都 是 整数 类 型 呀 ， 应 该 是 double 
类 型 或 者 BigDecimal 类 型 呀 。 是 ， 一 般 非 银行 的 交易 系统 ， 比 如 超市 的 
收银 系统 ， 系 统 内 都 是 存放 的 int 类 型 ， 在 显示 的 时 候 才 转换 为 货币 类 
人 Hs 





交易 信息 Trade 类 ， 负 责 记录 每 一 笔 交 易 ， 它 是 由 监听 程序 监听 MQ 
队列 而 产生 的 ， 有 两 个 属性 : 交易 编号 和 交易 金额 ， 其 中 的 交易 编号 对 
整个 交易 非常 重要 ，18 位 字符 在 银行 的 交易 系统 中 ， 这 里 可 不 是 字符 
串 ， 一 般 是 十 进 制 数 字 或 二 进 制 数字 ， 要 考虑 系统 的 性 能 ， 数 字 运 算 可 
比 字符 运算 快 得 多 ) ， 包 括 POS 机 编号 、 商 己 编 号 、 校 验 码 等 ， 我 们 这 
里 暂时 用 不 到 ， 就 不 多 做 介绍 ， 我 们 只 要 知道 它 是 一 个 非常 有 用 的 编码 
就 成 。 交 易 金 额 为 整数 类 型 ， 实 际 金额 放大 100 倍 即 可 。 如 代码 清单 35- 
2 所 示 。 








代码 清单 35-2 交易 类 


public class Trade { 
// 交 易 编号 


private String tradeNo = ""， 

// 交 易 金额 

private int amount = 0; 

//getter/setter 方 法 

public String getTradeNo() { 
return tradeNo; 








public void setTradeNo(String postNo) { 
this.tradeNo = postNo; 


public int getAmount() { 
return amount; 


public void setAmount(int amount) { 
this.amount = amount ， 
} 


两 个 最 简单 也 是 在 应 用 中 最 常 使 用 的 对 象 定义 完毕 ， 下 面 束 需要 来 
定义 策略 了 ， 非 第 明显 的 策略 模式 ， 类 图 如 图 35-2 所 示 。 





典型 的 策略 模式 ， 扣 丈 有 两 种 策略: 固定 扣 球 和 自由 扣 丈 。 下 面 我 
们 来 看 代码 ， 先 看 抽象 策略 ， 也 就 是 扣 球 接口 ， 如 代码 清单 35-3 所 示 。 


代码 清单 35-3 扣 天 策略 接口 


public interface IDeduction { 
// 扣 款 ， 提 供 交 易 和 卡 信息 ， 进 行 扣 款 ， 并 返回 扣 款 是 否 成 功 
public boolean exec(Card card,Trade trade ) ; 











固定 扣 亚 的 规则 是 固定 金额 和 目 由 金额 各 扣除 交易 金额 的 一 半 ， 如 
代码 清单 35-4 所 示 。 


代码 清单 35-4 扣 款 策略 一 


public class SteadyDeduction implements IDeduction { 


// 固 定性 交易 扣 球 

public boolean exec(Card card, Trade trade) { 
// 固 定金 额 和 自由 金额 各 扣除 50% 
int halfMoney = (int)Math.rint(trade.getAmount() / 2 
card.setFreeMoney(card.getFreeMoney() - halfMoney); 
card.setSteadyMoney(card.getSteadyMoney() - halfMone 
return true; 








| +DeductionContext(IDeduction _deduction) 
+boolean exec(Card card, Trade trade) 


<<imnterface>> 


IDeduction 


+boolean exec(Card card, Trade trade) 






FreeDeduction 
-a 
= 





图 35-2 扣 球 入 略 类 图 


这 个 有 具体 策略 也 非常 简单 ， 就 是 两 个 金额 各 目 减 去 交易 额 的 一 半 
(注意 除数 是 2.0， 可 不 是 2) ， 然 后 再 四 舍 五 入 ， 算 法 确实 简单 。 该 逻 
辑 没有 考虑 账户 余额 不 足 的 情况 ， 也 没有 考虑 异常 情况 ， 比 如 并 友情 
况 ， 读 者 可 以 想 想 看 ， 一 张 卡 有 两 笔 消 费 同 时 发 生 时 ， 征 不 是 就 发 生 错 
误 了 ? 一 张 卡 同时 有 两 笔 消费 会 出 现 这 种 情况 吗 ? 会 的 ， 网 络 阻 压 的 情 
况 ，MQ 多 通道 友 送 ， 在 网 络 繁忙 的 情况 下 是 有 可 能 出 现 该 问题 ， 这 里 
就 不 多 介绍 ， 有 兴趣 的 读者 可 以 看 看 MQ 的 资料 。 我 们 在 这 里 的 讲解 实 
现 的 是 一 个 快乐 路 径 ， 认 为 所 有 的 交易 都 是 在 安全 可 靠 的 环境 中 发 生 
的 ， 并 且 所 有 的 系统 环境 都 满足 我 们 的 要 求 。 我 们 再 来 看 男 一 个 策略 ， 
这 个 策略 更 简单 ， 如 代码 清单 35-5 所 示 。 











代码 清单 35-5 扣 款 策略 二 


public class FreeDeduction implements IDeduction { 
/自由 扣 款 
public boolean exec(Card card, Trade trade) { 
// 直 接 从 自由 余额 中 扣除 
card.setFreeMoney(card.getFreeMoney() - trade.getAmo 
return true; 





























卡 内 的 目 由 金额 减 去 交易 金额 再 修改 卡 内 上 自由 金额 就 完事 了 了， 有 异 季 
情况 不 考虑 。 这 两 个 具体 的 策略 与 我 们 的 交易 类 型 没有 任何 关系 ， 也 不 
应 该 有 关系 ， 集 上 略 模式 就 是 提供 两 个 可 以 相互 蔡 换 的 策略 ， 至 于 在 什么 
时 候 使 用 什么 策略 ， 则 不 是 由 集 略 模式 来 决定 的 。 集 略 模 式 还 有 一 个 角 
色 没 出 场 ， 即 封装 角色 ， 如 代码 清单 35-6 所 示 。 








代码 清单 35-6 扣 丈 策略 的 封 效 


public class DeductionContext { 


// 扣 球 策 略 

private IDeduction deduction = null; 

// 构 造 函 数 传递 策略 

public DeductionContext(IDeduction _deduction){ 
this.deduction = _deduction,; 

} 

// 执 行 扣 款 


public boolean exec(Card card,Trade trade)t{ 
return this.deduction.exec(card, trade); 
} 





典型 的 策略 上 下 文 角色 。 扣 球 模块 的 策略 已 经 定义 完毕 了 ， 然 后 需 
要 想 办 法 解决 策略 模式 的 缺陷 : 它 把 所 有 的 策略 类 都 暴露 出 去 ， 暴 露 得 
越 多 以 后 的 修改 风险 也 就 越 大 。 怎 么 修改 呢 ? 增 加 一 个 映射 配置 文件 ， 
实现 策略 类 的 隐藏 。 我 们 使 用 枚 举 担 当 此 任 ， 对 策略 类 进行 映射 处 理 ， 
避免 高 层 模块 直接 访问 策略 类 ， 同 时 由 工厂 方法 模式 根据 映射 产生 策略 
对 象 ， 类 图 如 图 35-3 所 示 。 
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图 35-3 策略 工厂 类 图 


又 是 一 个 简单 得 不 能 再 简单 的 模式 一 一 工厂 方法 模式 ， 通 过 
StrategyMan 人 负 贡 对 具体 集 略 的 映射 ， 如 代码 清单 35-7 所 示 。 





代码 清单 35-7 策略 枚 举 


public enum StrategyMan { 
SteadyDeduction("com,cbf41ife,common,SteadyDeduction'")， 
FreeDeduction("com.cbf41life.common.FreeDeduction"); 


String value = ""，; 
private StrategyMan(String _value)t{ 
this.value = _value; 


} 

public String getValue(){ 
return this.value; 

} 








类 似 的 代码 解释 过 很 多 裔 了 ， 不 再 多 说 ， 它 束 是 一 个 登记 容器 ， 所 
有 的 具体 策略 都 在 这 里 登记 ， 然 后 提供 给 工厂 方法 模式 。 策 略 工 厂 如 代 
码 清单 35-8 所 示 。 


代码 清单 35-8 策略 工厂 


public class StrategyFactory { 
// 策 略 工 厂 
public static IDeduction getDeduction(StrategyMan strategy)t 
IDeduction deduction = null; 
try { 
deduction = (IDeduction)Class.forName(strategy. 
} catch (Exception e) { 
// 异常 处 理 


























return deduction; 


一 个 简单 的 工厂 ， 根 据 集 略 管 理 类 的 枚 举 项 创建 一 个 策略 对 象 ， 简 
单 而 实用 ， 策 略 模 陈 的 缺陷 也 弥补 成 功 。 那 这 么 复杂 的 系统 怎么 让 高 层 
模块 访问 ? 《你 看 不 出 复杂 ? 那 是 因为 我 们 写 的 都 是 快乐 路 径 ， 太 多 情 
况 都 没有 考虑 ， 在 实际 项 目 中 仪 瑟 并 友人 处 理 和 事务 管理 这 两 部 分 束 够 你 
头疼 了 。) 既然 系统 很 复 淋 ， 是 不 是 需要 封装 一 下 。 我 们 请 出 门面 模式 
进行 封装 ， 如 代码 清单 35-9 所 示 。 











代码 清单 35-9 扣 款 模块 封装 


public class DeductionFacade { 
// 对 外 公布 的 扣 款 信息 
public static Card deduct(Card card,Trade trade)t{ 
// 获 得 消费 策略 
StrategyMan reg = getDeductionType(trade ) ; 
// 初 始 化 一 个 消费 策略 对 象 





IDeduction deduction = StrategyFactory .getDeduction( 
// 产 生 一 个 策略 上 下 文 

DeductionContext context = new Deductioncontext(dedu 
// 进 行 扣 款 处 理 
context.exec(card, trade); 
// 返 回扣 款 处 理 完 毕 后 的 数据 


return card; 
































} 
// 获 得 对 应 的 商户 消费 策略 
private static StrategyMan getDeductionType(Trade trade)t{ 
// 模 拟 操作 
if(trade.getTradeNo().contains("abc"))t{ 
return StrategyMan.FreeDeduction; 
}elsef 


} 


return StrategyMan.SteadyDeduction; 





这 次 为 什么 要 驳 展 示 代 码 而 后 写 类 疼 呢 ? 那 是 因为 这 段 代码 比 写 类 
图 更 能 让 你 理解 。 读 者 注意 一 下 getDeductionType 方 法 ， 这 个 方法 在 实 
际 项 目 中 是 存在 的 ， 但 是 与 上 面 的 写法 有 天 塘 之 别 ， 因 为 在 实际 项 目 
中 ， 数 据 库 中 保存 了 策略 代码 与 交易 编码 的 对 应 关系 ， 直 接 通过 数据 库 
的 SQL 语 句 束 可 以 返回 对 应 的 扣 球 策略 。 这 里 我 们 采用 大 家 最 熟悉 的 条 
件 转 移 来 实现 ， 也 是 比较 清晰 和 容易 理解 的 。 














可 能 读者 要 问 了 ， 在 门面 模式 中 己 经 明确 地 说 明 ， 门 面 类 中 不 允许 
有 业务 迎 辑 存在 ， 但 是 你 这 里 还 是 有 了 一 个 getDeductionType 方 法 ， 它 
可 代表 的 是 一 个 判断 逻辑 蚜 ， 这 是 为 什么 昵 ?是 的 ， 该 方法 完全 可 以 移 
到 其 他 Hepler 类 中 ， 由 于 我 们 是 示例 代码 ， 暂 没有 明确 的 业务 含义 ， 故 
编写 在 此 处 ， 读 者 在 实际 应 用 中 ， 请 把 该 方法 放置 到 其 他 类 中 。 


好 ， 所 有 用 到 的 模式 都 介绍 完毕 了 ， 我 们 把 完整 的 类 图 整理 一 下 ， 


如 图 35-4 所 示 。 
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图 35-4 扣 球 子 模块 完整 类 图 











真实 系统 比 这 复杂 得 多 ， 有 了 我 们 之 前 的 分 析 ， 这 个 图 还 是 比较 容 
易 看 懂 的 。 我 们 所 有 的 开发 都 完成 了 ， 是 不 是 应 该 写 一 个 测试 类 来 展示 
一 下 我 们 的 成 果 ， 如 代码 清单 35-10 所 示 。 


代码 清单 35-10 场景 类 


public class Client { 
// 模 拟 交易 
public static void main(String[] args) { 
// 初 始 化 一 张 IC 卡 
Card card = OLLI 
// 显 未 下 内 信息 心 \ 
System. OUt ， printJln( "======== 初 始 卡 信息 : 天 三 王 三 三 三 二 三 三 信 ) 
ShowCard(card ) ， 
是 否 停 止 运 行 标志 
boolean flag = true; 
while(flag)t 
Trade trade = createTrade( ); 
DeductionFacade.deduct(card, trade); 


// 交 易 成 功 ， 打 印 出 成 功 处 理 消 妃 





















































System Out ， .print1in(trade. getTradeNo( )+" 交易 
System.out.println(" 本 次 发 生 的 交易 金额 为 : 
trade.getAmount()/100.0+" 元 "); 
// 展 示 一 下 内 信息 
ShowCard(card ) ， 
System.out.print("\n 是 否 需 要 退出 ? (Y/N)"); 
if(getInput().equalsIgnoreCase("y"))t{ 
flag = false; // 退 出 
} 























} 


} 

// 初 始 化 一 个 IC 卡 

private static Card initIC()t{ 
Card card = new Card(); 
card.setCcardNo("1100010001000"); 
card.setFreeMoney(100000); //1000 元 
card.setSteadyMoney(80000); //800 元 
return card; 





} 

// 产 生 一 条 交易 

private static Trade createTrade(){ 
Trade trade = new Trade(); 
System.out.print(" 请 输入 交易 编号 : "); 
trade.setTradeNo(getIinput( )); 
System.out,.print(" 请 输入 交易 金额 : " ) ; 
trade.setAmount(Integer.parseInt(getInput())); 
// 返 回 交 易 
return trade; 














// 打 印 出 当前 卡 内 交易 余额 

public static void showCard(Card card)t{ 
System.out.println("IC 卡 编写 :" + card.getcardNo()); 
System,out.println(" 固 定 类 型 余额 : "+ card,getSteadyMonk 
System.out.println(" 自 由 类 型 余额 : "+ card.getFreeMoney| 

















} 

// 获 得 键盘 输入 

public static String getInput(){ 
String str ="",; 
try { 


str=(new BufferedReader(new InputStreamReader( 
} catch (IOException e) { 
// 异 名 处 理 
} 


return str; 





























类 比较 长 ， 耐 心 看 还 是 非常 简单 的 ， 对 其 中 Client 类 的 方法 说 明 如 


einitIC 方 法 


初始 化 一 张 IC 卡 ， 方 便 进 行 测试 。 


e@ createTrade 方 法 





创建 一 笔 交 易 ， 完 成 测试 任务 。 
e@ showCard 方 法 
显示 IC 卡 内 的 信息 。 


e getInput 方 法 


获得 从 键盘 输入 的 字符 ， 以 回 车 符 作为 终结 标志 。 





方法 介绍 完毕 了 ， 我 们 运行 一 下 看 看 ， 结 果 如 下 所 示 : 








-=======- 初始 卡 信息 ，========= 


IC 卡 编号 :1100010001000 








回 定 类 型 余 


强 


: 800.0 元 











自由 类 型 余额 : 1000.0 元 















































abcdef 交易 成 功 ! 
本 次 发 生 的 交易 金额 为 : 100.0 元 


IC 卡 编号 :1100010001000 








固定 类 型 余额 : 800.0 元 

















自由 类 型 余额 : 900.0 元 





























是 否 需要 退出 ? (Y/N) 





我 们 模拟 了 一 笔 目 由 消 宽 ， 直 接 从 目 由 类 型 金额 中 扣除 了 。 我 们 再 
模拟 一 笔 固 定 类 型 的 消费 ， 运 行 结果 如 下 所 示 : 














-=======- 初始 卡 信息 : 


IC 卡 编号 :1100010001000 





固定 类 型 余额 : 800.0 元 








自由 类 型 余额 : 1000.0 元 

















请 输入 交易 编号 : abcdef 


























请 输入 交易 金额 : 10000 





abcdef 交易 成 功 ! 
本 次 发 生 的 交易 金额 为 : 100.0 元 


IC 卡 编 号 :1100010001000 








固定 类 型 余额 : 800.0 元 

















自由 类 型 余额 : 900.0 元 


























是 否 需 要 退出 ? (Y/N)n 














请 输入 交易 编号: 1001 

















请 输入 交易 金额 : 1234 





1001 交易 成 功 ! 
本 次 发 生 的 交易 金额 为 : 12.34 元 


IC 卡 编号 :1100010001000 








固定 类 型 余额 : 793.83 元 




















自由 类 型 余额 : 893.83 元 


























是 否 需要 退出 ? (Y/N) 


交易 成 功 ! 到 这 里 为 止 ， 联 机 交易 中 的 扣 球 子 模 块 开 友 完毕 了 ! 是 


不 是 很 简单 ， 银 行业 的 交易 系统 也 就 是 这 么 回 事 ! 


35.2 混 编 小 结 


回顾 一 下 我 们 在 该 案例 中 使 用 了 几 个 模式 。 
e 策略 模式 


负责 对 扣 球 策略 进行 封装 ， 保 证 两 个 集 略 可 以 自由 切换 ， 而 且 日 后 
增加 扣 丈 集 略 也 非常 简单 容易 。 








修正 策略 模式 必须 对 外 暴露 具体 策略 的 问题 ， 由 工厂 方法 模式 下 接 
产生 一 个 具体 集 略 对 象 ， 而 其 他 模块 则 不 需要 依赖 具体 的 集 略 。 


e 门面 模式 


负责 对 复杂 的 扣 秋 系 统 进行 封装 ， 封 装 的 结 末 惑 是 避免 高 层 模块 深 
入 子 系统 内 部 ， 同 时 提供 系统 的 高 内 聚 、 低 耦合 的 特性 。 





我 们 主要 使 用 了 这 三 个 模式 ， 它 们 的 好 处 是 灵活 、 稳 定 ， 我 们 可 以 
设想 一 下 可 能 有 哪些 业务 变化 。 


e 扣 殖 策略 变更 


增加 一 个 新 扣 款 策略 ， 三 步 就 可 以 完成 : 实现 IDeduction 接 口 ， 增 


加 StrategyMan 配 置 项 ， 扩 展 扣 丈 策 略 的 利用 (也 就 是 门面 模式 的 
getDeductionType 方 法 ， 在 实际 项 目 中 这 里 只 需要 增加 数据 库 的 配置 
项 ) 。 减 少 一 个 打上 略 很 简单 ， 修 改 扣 丈 集 略 的 利用 即 可 。 变 更 一 个 扣 球 
打上 略 也 很 简单 ， 扩 展 一 个 实现 类 口 残 可 以 了 。 











e 变更 扣 球 集 略 的 利用 规则 


我 们 的 系统 不 想 大 修改 ， 还 记得 我 们 提出 的 状态 模式 吗 ? 这 个 就 是 
为 策略 的 利用 服务 的 ， 变 更 它 就 能 满足 要 求 。 想 把 IC 卡 也 纳入 策略 利用 
的 规则 也 不 复杂 。 其 实 这 个 变更 还 真 发 生 了 ， 系 统 投产 后 ， 业 务 提出 考 
虑 退休 和 人员 的 情况 ， 退 体 人 员 的 IC 卡 与 普通 在 职员 工 一 样 ， 但 是 它 的 扣 
款 不 仅仅 是 根据 交易 编码 ， 还 要 根据 IC 卡 对 象 ， 系 统 的 变更 做 法 是 增加 
一 个 扣 款 策略 ， 同 时 扩展 扣 款 利用 策略 ， 也 就 是 数据 库 的 配置 项 ， 在 
getDeductionType 中 新 扩展 了 一 个 功能 : 根据 IC 卡号 ， 确 认 是 否 是 退休 
人 员 ， 是 退休 人 员 ， 则 使 用 新 的 扣 款 策略 ， 这 是 一 个 非常 简单 的 扩展 。 








这 就 是 一 个 mini 厂 的 金融 交易 系统 ， 没 啥 复杂 的 ， 剩 下 的 问题 就 是 


开始 考虑 系统 的 鲁 棒 性 ， 这 才 是 难点 。 


第 36 章 ”观察 者 模式 + 中 介 者 模式 


36.1 事件 触及 右 的 开 友 


大 家 都 应 该 做 过 桌面 程序 的 开发 吧 ， 比 如 编写 一 个 EXE 文 件 ， 或 者 
使 用 Java Swing 编 写 一 个 应 用 程序 ， 或 者 是 用 Delphi、C 编 写 C/S 结 构 的 
应 用 系统 ， 即 使 这 些 都 没有 做 过 ， 那 也 总 编写 过 B/S 结构 的 页 面 吧 ? 回 
忆 一 下 开发 过 程 ， 大 家 是 不 是 经 常 使 用 文本 框 和 按钮 这 两 个 控件 ?比如 
设计 一 个 按钮 ， 那 总 要 编写 鼠标 点 击 处 理 ， 你 是 不 是 这 样 开发 : 在 按钮 
的 onClick 函 数 中 编写 自己 的 逻辑 代码 ， 然 后 鼠标 点 击 测试 ， 该 代码 就 会 
运行 。 大 家 有 没有 想 过 为 什么 我 们 点 击 了 按钮 就 会 触发 我 们 自己 编写 的 
代码 呢 ? 浏览 器 怎么 知道 操作 者 按 了 按钮 要 触发 该 事件 呢 ? 鼠标 点 击 动 
作 、 按 钮 、 自 己 编写 的 代码 之 间 是 如 何 关 联 起 来 呢 ? 














我 们 今天 的 任务 就 是 来 模拟 类 似 触发 过 程 。 我 们 这 样 分 析 : 有 一 个 
产品 《不 管 是 Frame 还 是 Button 或 者 是 Radio) ， 它 有 多 个 触发 事件 ， 它 
产生 的 时 候 触发 一 个 创建 事件 ， 修 改 的 时 候 触 发 修改 事件 ， 删 除 的 时 候 
触发 删除 事件 ， 这 束 类 似 于 我 们 的 文本 框 ， 初 始 化 《也 就 是 创建 ) 的 时 
候 要 触发 一 个 onLoad 或 onCreate 事 件 ， 修 改 的 时 候 触 及 onChange 事 件 ， 
双击 (类 似 于 删除 ) 的 时 候 又 触发 onDbClick 事 件 ， 我 们 今天 的 目标 就 是 来 


思考 怎么 实现 这 样 一 个 架构 。 





设计 部 是 先 易 后 难 ， 我 们 先 从 最 简单 的 部 分 入 手 。 首 先 需 要 一 个 产 

， 并 且 该 产品 要 有 创建 、 修 改 、 销 毁 的 动作 ， 很 明显 这 就 是 一 个 工 广 
方法 模式 。 同 时 产品 也 可 以 通过 克隆 方式 产生 ， 这 与 我 们 在 GUI 设计 中 
经 党 使 用 的 复制 粘贴 操作 相 类 似 ， 要 不 界面 上 那么 多 的 文本 框 ， 不 使 用 
复制 粘贴 ， 不 累 死 人 才 怪 呢 ， 那 这 非常 明显 就 是 原型 模式 。 好 ， 分 析 到 
这 里 ， 我 们 先 把 这 部 分 的 类 图 建立 起 来 ， 如 图 36-1 所 示 。 

















很 熟悉 的 类 图 ， 与 工厂 方法 模式 的 通用 类 图 非常 相似 ， 但 不 完全 

。 有 什么 差别 呢 ? 注意 看 产品 类 的 私有 属性 canChanged 和 构造 函数 ， 
它们 有 特殊 的 用 途 。 在 该 类 图 中 ， 我 们 使 用 了 工厂 方 法 模式 创建 产品 ， 
使 用 原型 模式 让 对 象 可 以 被 拷贝 ,仅仅 这 两 个 模式 还 不 足以 解决 我 们 的 
问题 ， 想 想 看 ， 产 品 的 产生 是 有 一 定 的 条 件 的， 不 是 谁 想 产生 就 产生 ， 
否则 怎么 能 够 触发 创建 事件 呢 ? 因此 需要 限定 产品 的 创建 者 ， 所 以 我 们 
在 类 图 中 把 产品 和 工厂 的 关系 定位 为 组 合 关 系 ， 而 不 是 简单 的 聚集 或 依 
赖 关系 。 换 句 话 说 ， 产 品 只 能 由 工厂 类 创建 ， 而 不 能 被 其 他 对 象 通过 
new 方 式 创建 ， 因 此 我 们 在 这 里 还 用 到 一 个 单 来 源 调用 〈Single Call) 方 
法 解决 该 问题 。 这 是 一 个 方法 ， 不 是 一 个 设计 模式 ， 我 马上 给 大 家 讲解 
它 是 如 何 工 作 的 。 

















产品 工厂 















-String name 
+Product createProduct(String name) -boolean canChanged = false 


+void abandonProduct(Product p) +Product(ProductManager manager, String name) 
+void editProduct(Product p, String name) +String getName() 


ProductManager 
-boolean isPermittedCreate = false 





+boolean isCreateaProduct() +void setName(String name) 
+Product clone(Product p) +Product clone() 


图 36-1 产品 创建 工厂 


我 们 先 来 看 产品 类 的 源 代码 ， 它 比较 人 简单， 如 代码 清单 36-1 所 示 。 


代码 清单 36-1 产品 类 


public class Product implements Cloneablef{ 
// 产 品名 称 
private String name; 
// 是 否 可 以 属性 变更 
private boolean canChanged = false; 
// 产 生 一 个 新 的 产品 
public Product(ProductManager manager,String _name)t{ 
// 人 允许 建立 产品 
if(manager.isCreateProduct())t{ 
canChanged =true; 
this.name = _name; 











} 

} 

public String getName() { 
return name; 


public void setName(String name) { 
if(canChanged)t 
this.name = name; 
} 


} 
// 和 窗 写 clone 方 法 
Q@Override 





public Product clone(){ 
Product p =null; 


try { 
p =(Product)super.clone(); 

} catch (CloneNotSupportedException e) { 
e.printStackTrace( ); 

} 


return p; 


在 产品 类 中 ， 我 们 只 定义 产品 的 一 个 属性 : 产品 名 称 Cname) ， 并 
实现 了 gettersetter 方 法 ， 然 后 我 们 实现 了 它 的 clone 方 法 ， 确 保 对 象 是 可 
以 被 拷贝 的 。 还 有 一 个 特殊 的 地 方 是 我 们 的 构造 浮 数 ， 它 怎么 会 要 求 传 
递 进来 一 个 工厂 对 象 ProductManager 呢 ?保留 你 的 好 奇 心 ， 马 上 为 你 揭 
晓 答案 。 我 们 继续 看 代码 ， 工 厂 类 如 代码 清单 36-2 所 示 。 


代码 清单 36-2 工厂 类 


public class ProductManager { 

// 是 否 可 以 创建 一 个 产品 

private boolean isPermittedCreate = false; 

// 建 立 一 个 产品 

public Product createProduct(String name)t{ 
// 首 先 修改 权限 ， 允 许 创建 
isPpermittedCreate = true; 
Product p = new Product(this,name); 
return p; 











} 

// 废 弃 一 个 产品 

public void abandonProduct(Product p)t{ 
// 销 毁 一 个 产品 ， 例 如 删除 数据 库 记 录 
p = null; 


} 

// 修 改 一 个 产品 

public void editProduct(Product p,String name)t{ 
// 修 改 后 的 产品 
p.setName (name); 








/获得 是 否 可 以 创建 一 个 产品 


public boolean isCreateProduct(){ 
return isPermittedCreate,; 


} 

// 克 隆 一 个 产品 

public Product clone(Product p){ 
// 产 生死 隆 事件 
return p.clone(); 





} 


仔细 看 看 工厂 类 ， 产 品 的 创建 、 修 改 、 遗 弃 、 殉 隆 方法 都 很 简单 ， 
但 有 一 个 方法 可 不 简单 一 isCreateProduct 方 法 ， 它 的 作用 是 告诉 产品 
类 “我 是 能 创建 产品 的 "， 注 意 看 我 们 的 程序 ， 在 工厂 类 ProductManager 
中 定义 了 一 个 私有 变量 isCreateProduct， 该 变量 只 有 在 工厂 类 的 
createProduct 函 数 中 才能 设置 为 tue， 在 创建 产品 的 时 候 ， 产 品类 Product 
的 构造 函数 要 求 传递 工厂 对 象 ， 然 后 判断 是 否 能 够 创建 产品 ， 即 使 你 想 
使 用 类 似 这 样 的 方法 : 








Product p = new Product(new ProductManager(),"abc"); 





也 是 不 可 能 创建 出 产品 的 ， 它 在 产品 类 中 限制 必须 是 当前 有 效 工 ) 
才能 生产 该 产品 ， 而 且 也 只 有 有 效 的 工厂 才能 修改 产品 ， 看 看 产品 类 的 
canChanged 属 性 ， 只 有 它 为 tue 时 ， 产 品 才 可 以 修改 ， 那 怎么 才能 为 true 
呢 ? 在 构造 函数 中 判断 是 否 可 以 为 tue。 这 就 类 似 工厂 要 创建 产品 了 ， 
产品 就 问 “ 你 有 权利 创建 我 吗 ? ”于 是 工厂 类 出 示 了 两 个 证 明 材 料 证 明 上 自 
己 可 以 创建 产品 :一 是 “我 是 你 的 工厂 类 ”， 二 是 “我 的 isCreateProduct 返 
回 true， 我 有 权 创 建 >， 于 是 产品 就 被 创建 出 来 了 。 这 种 一 个 对 象 只 能 
固定 的 对 象 初始 化 的 方法 就 叫做 单 来 源 调 用 〈Single Cal ) 一 一 很 简 

















单 ， 但 非常 有 用 的 方法 。 


注意 “采用 单 来 源 调 用 的 两 个 对 象 一 般 是 组 合 基 系 ， 两 者 有 相同 
的 生命 期 ， 它 通常 适用 于 有 单 例 模式 和 工厂 方法 模式 的 场景 





我 们 继续 往 下 分 析 ， 一 个 产品 新 建 要 触发 事件 ， 那 事件 是 什么 ? 当 
然 也 是 一 个 对 象 了 ， 需 要 把 它 设计 出 来 ， 仅 仅 有 事件 还 不 行 ， 还 要 考虑 
有 人 去 处 理 这 个 事件 ， 产 生 了 一 个 事件 不 可 能 没有 对 象 去 处 理 吧 ? 如 果 
是 这 样 那 事件 还 有 什么 意义 呢 ? 既然 要 去 处 理 ， 那 就 需要 一 个 通知 渠道 
了 ， 于 是 观察 者 模式 准备 好 了 。 好 ， 我 们 把 这 段 分 析 的 类 图 也 画 出 来 ， 
如 图 36-2 所 示 。 








<<interface>> 
Observable 
Observer 





ProductEvent EventDispatch 











-Product Source; -EventDispatch dispatch 
Ee -EventDispatch() 


+Product getSource() 
+ProductEventType getEventType() 
-void notifyEventDispatch() 









+EventDispatch getEventDispathc() 
+void update(Observable o, Object arg) 


事件 通知 对 象 人 








<<enumeration>> 
ProductEventType 


+NEW_ PRODUCT(I) 
+DEL PRODUCTO2) 
+EDIT PRODUCT(3) 
+CLONE PRODUCT(4) 


+ProductEventType(int _value) 
+int getValue() 












图 36-2 观察 者 模式 处 理事 件 


在 该 类 图 中 ， 观 察 者 为 EventDispatch 类 ， 它 使 用 了 单 例 模式 ， 避 免 
对 和 象 膨胀 ， 但 同时 也 带 来 了 性 能 及 线程 安全 隐患 ， 这 点 需要 大 家 在 实际 
应 用 中 注意 〈 想 想 Spring 中 的 Bean 注 入 ， 默 认 也 是 单 例 ， 在 通常 的 应 用 
中 一 般 不 需要 修改 ， 除 非 是 较 大 并 发 的 应 用 ) 。 我 们 来 看 代码 ， 先 来 看 
事件 类 型 定义 ， 它 是 一 个 枚 举 类 型 ， 如 代码 清单 36-3 所 示 。 





代码 清单 36-3 事件 类 型 定义 


public enum ProductEventType { 
// 新 建 一 个 产品 
NEW_PRODUCT(1), 
// 删 除 一 个 产品 
DEL_PRODUCT(2)， 
// 修 改 一 个 产品 
EDIT_PRODUCT(3), 
// 克 隆 一 个 产品 
CLONE_PRODUCT(4); 
private int value=0; 
private ProductEventType(int _value)t{ 

this.value = _value; 





public int getValue(){ 
return this.value; 
} 


这 里 定义 了 4 个 事件 类 型 ， 分 别 是 新 建 、 修 改 、 删 除 以 及 克隆 ， 
较 简 单 。 我 们 再 来 看 产品 的 事件 ， 如 代码 清单 36-4 所 示 。 


代码 清单 36-4 产品 事件 


public class ProductEvent extends Observablef 
// 事 件 起 源 
private Product source; 
// 事 件 的 类 型 
private ProductEventType type 
// 传 入 事件 的 源头 ， 默 认为 新 建 类 型 
public ProductEvent(Product p) { 
this(p,ProductEventType.NEW_ PRODUCT); 
} 


// 事 件 源 头 以 及 事件 类 型 
public ProductEvent(Product p,ProductEventType _type) 
this.source = p; 
this.type = _type; 
// 事 件 触发 
notifyEventDispatch(); 


} 

// 获 得 事件 的 始作俑者 

public Product getSource( ){ 
return source; 

} 


// 获 得 事件 的 类 型 









































public ProductEventType getEventType( ){ 
return this.type; 























} 

// 通 知事 件 处 理 中 心 

private void notifyEventDispatch()t{ 
super.addOobserver(EventDispatch.getEventDispatch()); 
Super ,SetChanged() ， 
Super .notifyobservers(Source ) ; 








我 们 在 产品 事件 类 中 增加 了 一 个 私有 方法 notfiyEventDispatch， 访 
方法 的 作用 是 明确 事件 的 观察 者 ， 并 同时 在 初始 化 时 通知 观察 者 ， 它 在 
有 参 构造 中 被 调用 。 我 们 再 来 看 事件 的 观察 者 ， 如 代码 清单 36-5 所 示 。 


代码 清单 36-5 事件 的 观察 者 


public class EventDispatch implements Observert{ 
// 单 例 模式 
private final static EventDispatch dispatch = new EventDispa 
// 不 允许 生成 新 的 实例 
private EventDispatch(){ 


} 

// 获 得 单 例 对 象 

public static EventDispatch getEventDispatch(){ 
return dispatch; 


} 
// 事 件 触发 
public void update(Observable o, Object arg) { 





产品 和 事件 都 定义 出 来 了 ， 那 我 们 想 想 怎么 把 这 两 者 关联 起 来 ， 产 
品 和 事件 是 两 个 独立 的 对 象 ， 两 者 都 可 以 独立 地 扩展 ， 用 什么 来 适应 它 
们 的 扩展 呢 ? 桥 梁 模 式 ! 两 个 不 相关 的 类 可 以 通过 桥梁 模式 组 合 出 稳 
定 、 健 壮 的 结构 ， 我 们 画 出 类 图 ， 如 图 36-3 所 示 。 


ProductEvent 


-Product source; 
-ProductEventType type 


-String name 
-boolean canChanged = false 












+ProductEvent(Product p) +String getName() 
+Product getSource() +vold setName(String name) 
+ProductEventType getEventType() +Product clone() 

-Vold notifyEventDispatch() 


ProductManager 


图 36-3 桥梁 模式 实现 产品 和 事件 的 组 合 


看 着 不 像 桥 梁 模式 ? 看 看 桥梁 模式 的 通用 类 图 ， 然 后 把 抽象 化 角色 
和 实现 化 角色 去 掉 看 看 ， 是 不 是 就 是 一 样 了 ? 各 位 可 能 要 说 了 ， 把 抽象 
化 角色 和 实现 化 角色 去 掉 ， 那 桥梁 模式 在 抽象 层次 耦合 的 优点 还 怎么 体 
现 呢 ? 因为 我 们 采用 的 是 单个 产品 对 象 ， 没 有 必要 进行 抽象 化 处 理 ， 读 
者 若 要 按照 该 框架 做 扩展 开发 ， 该 部 分 是 肯定 需要 抽象 出 接口 或 抽象 类 
的 ， 好 在 也 非常 简单 ， 只 要 抽取 一 下 就 可 以 了 。 这 样 考虑 后 ， 我 们 的 
ProductManager 类 就 增加 一 个 功能 : 组 合 产品 类 和 事件 类 ， 产 生 有 意义 
的 产品 事件 ， 如 代码 清单 36-6 所 示 。 

















代码 清单 36-6 修正 后 的 产品 工厂 类 


public class ProductManager { 
// 是 否 可 以 创建 一 个 产品 
private boolean isPermittedCreate = false; 








// 建 立 一 个 产品 

public Product createProduct(String name)t{ 
// 首 先 修改 权限 ， 允 许 创建 
isPpermittedCreate = true; 
Product p = new Product(this,name); 
// 产 生 一 个 创建 事件 
new ProductEvent(p,ProductEventType.NEW_ PRODUCT); 
return p; 











} 
// 废 弃 一 个 产品 
public void abandonpProduct(Product p)t{ 
// 销 毁 一 个 产品 ， 例 如 删除 数据 库 记 录 
// 产 生 删 除 事件 
new ProductEvent(p,ProductEventType.DEL PRODUCT); 
p = null; 





} 
// 修 改 一 个 产品 
public void editProduct(Product p,String name)t{ 
// 修 改 后 的 产品 
p.setName (name); 
// 产 生 修改 事件 
new ProductEvent(p,ProductEventType.EDIT_ PRODUCT).; 








} 

// 获 得 是 否 可 以 创建 一 个 产品 

public boolean isCreateProduct(){ 
return isPermittedCreate,; 


} 

// 克 隆 一 个 产品 

public Product clone(Product p)t 
// 产 生 克 隆 事件 
new ProductEvent(p,ProductEventType.CLONE_ PRODUCT); 
return p.clone(); 





在 每 个 方法 中 增加 了 事件 的 产生 机 制 ， 在 createProduct 方 法 中 增加 
了 创建 产品 事件 ， 在 editProduct 方 法 中 增加 了 修改 产品 事件 ， 在 
delProduct 方 法 中 增加 了 遗弃 产品 事件 ， 在 done 方 法 中 增加 元 隆 产 品 事 
件 ， 而 且 每 个 事件 都 是 通过 组 合 产生 的 ， 产 品 和 事件 的 扩展 性 非常 优 


秀 。 








刚刚 我 们 说 完了 产品 和 事件 的 关系 处 理 ， 现 在 回 到 我 们 事件 的 观察 
者 ， 它 承担 着 非常 重要 的 职责 。 我 们 知道 它 要 处 理事 件 ， 但 是 现在 还 没 
有 和 想 好 怎么 实现 它 处 理事 件 的 update 方 法 ， 暂 时 保持 为 空 。 








我 们 继续 分 析 ， 这 么 多 的 事件 (现在 只 有 1 个 产品 类 ， 如 果 产 品类 
很 多 呢 ?” 比 如 30 多 个 〉 不 可 能 每 个 产品 事件 都 写 一 个 处 理 者 吧 ， 对 于 产 
品 事件 来 说 ， 它 最 希望 的 结果 就 是 我 通知 了 事件 处 理 者 〈 也 就 是 观察 者 
模式 的 观察 者 ) ， 其 他 有 具体 怎么 处 理由 观察 者 来 解决 ， 那 现在 问题 是 观 
察 者 怎么 来 处 理 这 么 多 的 事件 呢 ? 事件 的 处 理 者 必然 有 N 多 个 ， 如 何 才 
能 通知 相应 的 处 理 者 来 处 理事 件 呢 ? 一 个 事件 也 可 能 通知 多 个 处 理 者 来 
处 理 ， 并 且 一 个 处 理 者 处 理 完 毕 还 可 能 通知 其 他 的 处 理 者 ， 这 不 可 能 让 
每 个 处 理 者 独自 完成 这 样 “ 不 可 能 完成 的 任务 ”， 我 们 把 问题 的 示意 图 画 
出 来 ， 如 图 36-4 所 示 。 




















图 36-4 事件 处 理 示 意图 


看 到 该 示意 图 ， 你 立刻 就 会 想到 中 介 者 模式 。 是 的 ， 需 要 中 介 者 模 
式 上 场 了 ， 我 们 把 EventDispatch 类 〈 嘿 嘿 ， 为 什么 要 定义 成 Dispatch 
呢 ? 就 是 分 发 的 意思 ) 作为 事件 分 发 的 中 介 者 ， 事 件 的 处 理 者 都 是 具体 
的 同事 类 ， 它 们 有 着 相似 的 行为 ， 都 是 处 理 产 品 事件 ， 但 是 又 有 不 相同 
的 逻辑 ， 每 个 同事 类 对 事件 都 有 不 同 的 处 理 行为 。 我 们 来 看 类 图 ， 如 图 




















36-5 所 示 。 
在 类 图 中 ，EventDispatch 类 有 3 个 职责 。 
e 事件 的 观察 者 


作为 观察 者 模式 中 的 观察 者 和 角色， 接收 被 观察 期 望 完 成 的 任务 ， 在 
我 们 的 框架 中 就 是 接收 ProductEvent 事 件 。 





e 事件 分 用 者 


作为 中 介 者 模式 的 中 介 者 角色 ， 它 担当 着 非常 重要 的 任务 一 一 分 发 
事件 ， 并 同时 协调 各 个 同事 类 (也 就 是 事件 的 处 理 者 ) 处理 事件 。 


e 事件 处 理 者 的 管理 员 角 色 





不 是 每 一 个 事件 的 处 理 者 都 可 以 接收 事件 并 进行 处 理 ， 是 需要 获得 
分 发 者 许可 后 才 可 以 ， 也 就 是 说 只 有 事件 分 友 者 允许 它 处 理 ， 它 
埋 





<<enumeration>> 
EventCustomType 


+NEW() 


<<interface>> 
Observer 





事件 处 理 者 的 类 型 


+DEL(?) 
+EDIT(3) 


+CLONE(4) 





EventDispatch 












EventCustomer 
-Vector customType -EventDispatch dispatch 


+EventCustomer(EventCustomType _type) < -EventDispatch() 
+void addCustomType(EventCustomType _type) +EventDispatch getEventDispathc() 


+Vector<EventCustomType> getCustomType() +void update(Observable o, Object arg) 
+void exec(ProductEvent event) +void registerCustomer() 






Noble man 
下 


图 36-5 采用 中 介 者 模式 对 事件 进行 分 发 








事件 分 发 者 担当 了 这 么 多 的 职责 ， 那 是 不 是 与 单一 职责 原则 相 违背 
了 ? 确实 如 此 ， 我 们 在 整个 系统 的 设计 中 确实 需要 这 样 一 个 角色 担任 这 
么 多 的 功能 ， 如 条 强制 细 分 也 可 以 完成 ， 但 是 会 加 大 代码 量 ， 同 时 导致 
系统 的 结构 复杂 ， 读 者 可 以 考虑 拆 分 这 3 个 职责 ， 然 后 再 组 合 相关 的 功 
能 ， 看 看 代码 量 是 如 何 翻 倍 的 。 











注意 ”设计 原则 只 是 一 个 理论 ， 而 不 是 一 个 珊 有 刻度 的 标 太 ， 因 
此 在 系统 设计 中 不 应 该 把 它 视 为 不 可 逾越 的 屏障 ， 而 是 应 该 把 它 看 成 是 





一 个 方 同 标 ， 尽 量 遵守 ， 而 不 是 必须 恪守 。 





既然 事件 分 发 者 这 么 重要 ， 我 们 就 仔细 研读 一 下 它 的 代码 ， 如 代码 
清单 36-7 所 示 。 


代码 清单 36-7 事件 分 发 者 


public class EventDispatch implements Observert{ 
// 单 例 模式 
private final static EventDispatch dispatch = new EventDispa 
// 事 件 消费 者 
private Vector<EventCustomer> customer = new Vector<EventCus 
// 不 允许 生成 新 的 实例 
private EventDispatch(){ 


} 

// 获 得 单 例 对 象 

public static EventDispatch getEventDispatch(){ 
return dispatch,; 

} 


// 事 件 触发 
public void update(Observable o, Object arg) { 
// 事 件 的 源头 
Product product = (Product)arg; 
// 事 件 
ProductEvent event = (ProductEvent)o; 
// 处 理 者 处 理 ， 这 里 是 中 介 者 模式 的 核心 ， 可 以 是 很 复杂 的 业务 多 划 
for(EventCustomer e:customer){ 
// 处 理 能 力 是 否 匹 配 
for(EventCustomType t:e.getCustomType())t{ 
if(t.getValue()== event.getEventType 
e.exec(event); 
} 



































IT 















































} 
} 
// 注 册 事 件 处 理 者 


public void registerCustomer(EventCustomer _customer){ 
customer.add(_customer ) ， 
} 


























我 们 在 这 里 使 用 Vector 来 存储 所 有 的 事件 处 理 者 ， 在 update 方法 中 
使 用 了 两 个 简单 的 for 循 环 来 完成 业务 馆 辑 的 判断 ， 只 要 事件 的 处 理 者 级 
别 和 事件 的 类 型 相 匹 配 ， 就 调用 事件 处 理 者 的 exec 方 法 来 处 理事 件 ， 该 
逻辑 是 整个 事件 触发 架构 的 关键 点 ， 但 不 是 难点 。 请 读者 注意 ， 在 设计 
这 样 的 框架 前 ， 一 定 要 定义 好 消费 者 与 生产 者 之 间 的 搭配 问题 ， 一 般 的 
做 法 是 通过 xml 文 件 关 或 者 IoC 容 器 配置 规则 ， 然 后 在 框架 局 动 时 加 载 并 
驻 留 内 存 。 








EventCustomer 抽 象 类 负责 定义 事件 处 理 者 必须 具有 的 行为 ， 首 先 
是 每 一 个 事件 的 处 理 者 都 必须 定义 自己 能 够 处 理 的 级 别 ， 也 就 是 通过 构 
造 函数 来 定义 自己 的 处 理 能 力 ， 当 然 处 理 能 力 可 以 是 多 值 的 ， 也 就 是 说 
一 个 处 理 者 可 以 处 理 多 个 事件 ;然后 各 个 事件 的 处 理 者 只 要 实现 exec 方 
法 就 可 以 了 ， 完 成 自己 对 事件 的 消费 处 理 即 可 。 我 们 先 来 看 抽象 的 事件 
处 理 者 ， 如 代码 清单 36-8 所 示 。 








代码 清单 36-8 抽象 的 事件 处 理 者 


public abstract class EventCustomer { 
// 容 纳 每 个 消费 者 能 够 处 理 的 级 别 
private Vector<EventCustomType> customType = new Vector<Even 
// 每 个 消费 者 都 要 声明 自己 处 理 哪 一 类 别 的 事件 
public EventCustomer(EventCustomType _type)t{ 
addCustomType(_type); 


} 

// 每 个 消费 者 可 以 消费 多 个 事件 

public void addCustomType(EventCustomType _type)t{ 
customType.add(_type); 


} 
// 得 到 自己 的 处 理 能 
public Vector<EventCustomType> getCustomType( ){ 




































































return customType; 


} 
// 每 个 事件 都 要 对 事件 进行 声明 式 消费 
public abstract void exec(ProductEvent event); 














很 简单 ， 我 们 定义 了 一 个 Vector 变量 来 存储 处 理 者 的 处 理 能 力 ， 然 
后 通过 构造 函数 约束 于 类 必须 定义 一 个 目 己 的 处 理 能 力 。 在 代码 中 ， 我 
们 用 到 了 事件 处 理 类 型 枚 举 ， 如 代码 清单 36-9 所 示 。 





代码 清单 36-9 事件 处 理 枚 举 


public enum EventCustomType { 
// 新 建立 事件 
NEW(1), 
// 删 除 事件 
DEL(2), 
// 修 改 事件 
EDIT(3), 
// 克 隆 事件 
CLONE(4); 
private int value=0; 
private EventCustomType(int _value)t{ 

this.value = _value; 











了 

public int getValue(){ 
return value; 

} 


wy 








我 们 在 系统 中 定义 了 3 个 事件 处 理 者 ， 分 别 是 乞丐 、 平 民 和 贵族 。 

只 能 获得 别人 遗弃 的 物品 ， 平 民 消 费 自 己 生产 的 东西 ， 自 给 自足 ， 
族 则 可 以 获得 精 修 的 产品 或 者 是 绿色 产品 《也 就 是 我 们 这 里 的 克隆 
产品 ， 不 用 自己 劳动 获得 的 产品 ) 。 我 们 先 看 乞丐 的 源 代 码 ， 如 代码 清 
单 36-10 所 示 。 


各 


5 
而 贯 











代码 清单 36-10 乞丐 


public class Beggar extends EventCustomer { 

// 只 能 处 理 被 人 遗弃 的 东西 
public Beggar(){ 

super(EventCustomType .DEL ) ; 




















@Override 
public void exec(ProductEvent event) { 
// 事 件 的 源头 
Product p = event.getSource( ); 
// 事 件 类 型 
ProductEventType type = event .getEVventType( ) 
System.out.println(" 乞 丐 处 理事 件 :"+p .getName() +" 销 毁 ， 和 





























乞丐 在 无 参 构造 中 定义 了 目 己 只 能 处 理 删除 的 事件 ， 然 后 在 exec 方 
法 中 定义 了 事件 的 处 理 逻 辑 ， 每 个 处 理 者 都 是 只 要 完成 这 两 个 方法 即 
可 ， 我 们 再 来 看 平民 级 别 的 事件 处 理 者 ， 如 代码 清单 36-11 所 示 。 


代码 清单 36-11 平民 


public class Commoner extends EventCustomer { 
// 定 义 平民 能 够 处 理 的 事件 的 级 别 
public Commoner() { 
super(EventCustomType .NEW); 


























@Override 
public void exec(ProductEvent event) { 
// 事 件 的 源头 
Product p = event.getSource( ) ; 
// 事 件 类 型 
ProductEventType type = event .getEVvVentType( ) ; 
System.out.println(" 平 民 处 理事 件 :"+p.getName( ) +" 诞 生 记 


























平民 只 处 理 新 建立 的 事件 ， 其 他 事件 不 做 处 理 ， 我 们 再 来 看 吐 族 级 


别 的 事件 处 理 者 ， 如 代码 清单 36-12 所 示 。 


代码 清单 36-12 贯 族 


public class Nobleman extends EventCustomer { 
// 定 义 贵族 能 够 处 理 的 事件 的 级 别 
public Nobleman() { 
super(EventCustomType .EDIT); 
super.addCustomType(EventCustomType.CLONE); 


























@Override 
public void exec(ProductEvent event) { 
// 事 件 的 源头 
Product p = event.getSource( ); 
// 事 件 类 型 
ProductEventType type = event .getEVvVentType( ) ; 
if(type.getValue() == EventCustomType.CLONE.getValue 
System.out .println(" 贵 族 处 理事 件 :"+p,getName() +" 
}elsef{ 
System.out.printlin(" 贵 族 处 理事 件 :"+p.getName() +" 






































贵族 稍 有 不 同 ， 它 有 两 个 处 理 能 力 ， 能 够 处 理 修改 事件 和 克隆 事 
件 ， 同 时 在 exec 方 法 中 对 这 两 类 事件 分 别 进行 处 理 。 此 时 ， 读 者 可 能 会 
想到 另外 一 个 处 理 模 式 ; 贡 任 链 模 式 。 建 立 一 个 链 ， 然 后 两 类 事件 分 别 
在 链 上 进行 处 理 并 反馈 结果 。 读 者 可 以 参考 一 下 Servlet 的 过 滤 右 
(Filter〉 的 设计 ， 在 框架 平台 的 开发 中 可 以 采用 该 模式 ， 它 具有 非常 好 
的 扩展 性 和 稳定 性 。 











所 有 的 角色 都 已 出 场 ， 我 们 建立 一 个 场景 类 把 它们 串联 起 来 ， 如 代 
码 清单 36-13 所 示 。 


代码 清单 36-13 场景 类 


public class Client { 
public static void main(String[] 

// 获 得 事件 分 发 中 心 
EventDispatch dispatch 
// 接 受 乞丐 对 事件 的 处 理 














args) 1{ 


EventDispatch.getEventDispa 


dispatch.registerCustomer(new Beggar()); 











// 接 受 平民 对 事件 的 处 理 


dispatch.registerCustomer(new Commoner()); 




















// 接 受 贵族 对 事件 的 处 理 





dispatch.registerCustomer(new Nobleman()); 











// 建 立 一 个 原子 弹 生 产 工厂 
ProductManager factory = 
// 制 造 一 个 产品 
System.out.println(" 





===== 模 拟 创 建 产 品 事 件 ======== 


new ProductManager(); 














System,out,printlLln(" 创 建 一 个 叫做 小 

















J 孩 的 原子 弹 " ) ; 


Product p = 
// 修 改 一 个 产品 


factory.createProduct(" 小 




















孩 原 子弹 ") ; 





















































System.out.println("\n===== 模 拟 修改 产品 事件 ========" )， 
System.out,println(" 把 小 男孩 原子 弹 修改 为 胖子 号 原子 弹 " ) ; 
factory.editProduct(p， "胖子 号 原子 弹 " ) ， 

// 再 克隆 一 个 原子 弹 
System.out.printlLln("NXn===== 模 拟 克 隆 产 品 事件 ========") 
System.out.printlLn(" 克 隆 胖 子 号 原子 弹 " ) ， 
factory.clone(p); 

// 遗 弃 一 个 产品 

System.out.println("\n===== 模 拟 销毁 产品 事件 ========" )， 
System.out,.printlLn(" 遗 弃 胖 子 号 原子 弹 " ) ; 





factory.abandonProduct(p); 


CE 


运行 结果 如 下 所 示 : 





===== 模 拟 创建 产品 事件 ======== 

















创建 一 个 叫做 小 男孩 的 原子 弹 



































平民 处 理 





事件 :小 男孩 原子 弹 诞 生 记 ,事件 类 




















把 小 男孩 原子 弹 修改 为 胖子 与 原子 








型 =NEW_PRODUCT 



































贵族 处 理事 件 :胖子 号 原子 弹 修改 ,事件 类 型 =EDIT_PRODUCT 


























[过 


克隆 胖子 号 原子 台 


















































贵族 处 理事 件 :胖子 号 原子 弹 克 隆 ,事件 类 型 =CLONE_PRODUCT 











-===- 模 拟 销毁 产品 事件 =======- 
遗弃 胖子 号 原子 弹 

































































乞丐 处 理事 件 :胖子 号 原子 弹 销 毁 , 事 件 类 型 =DEL_PRODUCT 





我 们 的 事件 处 理 框架 已 经 生效 了 ， 有 行为 ， 就 产生 事件 ， 并 有 处 理 
事件 的 处 理 者 ， 并 且 这 三 者 都 相互 解 耦 ， 可 以 独立 地 扩展 下 去 。 比 如 ， 
想 增加 处 理 者 ， 没 有 问题 ， 建 立 一 个 类 继承 EventCustomer， 然 后 注册 
到 EventDispatch 上 ， 就 可 以 进行 处 理事 件 了 ， 想 扩展 产品 ， 没 问题 ? 需 
要 稍稍 修改 一 下 ， 首 先 抽 取出 产品 和 事件 的 抽象 类 ， 然 后 再 进行 扩展 即 
可 。 





36.2 混 编 小 结 


该 事件 触发 框架 结构 清晰 ， 扩 展 性 好 ， 读 者 可 以 进行 抽象 化 处 理 后 
应 用 于 实际 开发 中 。 我 们 回头 看 看 在 这 个 案例 中 使 用 了 哪些 设计 模式 。 








负责 产生 产品 对 象 ， 方 便 产 品 的 修改 和 扩展 ， 并 且 实 现 了 产品 和 工 
三 的 紧 耦 合 ， 避 免 产品 随意 被 创建 而 无 触发 事件 的 情况 发 生 。 





e 桥梁 模式 


在 产品 和 事件 两 个 对 象 的 关系 中 我 们 使 用 了 桥梁 模式 ， 如 此 设计 
后 ， 两 者 都 可 以 自由 地 扩展 〈 前 提 是 需要 抽取 抽象 化 ) 而 不 会 破坏 原 有 
的 封装 。 





e 观察 者 模式 


观察 者 模式 解决 了 事件 如 何 通 知 处 理 者 的 问题 ， 而 且 观 察 者 模式 还 
有 一 个 优点 是 可 以 有 多 个 观察 者 ， 也 就 是 我 们 的 架构 是 可 以 有 多 层级 、 
多 分 类 的 处 理 者 。 想 重新 扩展 一 个 新 类 型 〈 新 接口 ) 的 观察 者 ? 没有 问 
题 ， 扩 展 ProductEvent 即 可 。 


e 中 介 者 模式 


事件 有 了 ， 处 理 者 也 有 了 ， 这 些 都 会 发 生变 化 ， 并 且 处 理 者 之 间 也 
有 耘 合 关系 ， 中 介 者 则 可 以 完美 地 处 理 这 些 复 杂 的 关系 。 





我 们 再 来 思考 一 下 ， 如 果 我 们 要 扩展 这 个 框架 ， 可 能 还 会 用 到 什么 
模式 ? 首先 是 责任 链 模 式 ， 它 可 以 帮助 我 们 解决 一 个 处 理 者 处 理 多 个 事 
件 的 问题 ， 其 次 是 模板 方法 模式 ， 处 理 者 的 启用 、 停 用 等 ， 都 可 以 通过 
模板 方法 模式 来 实现 ， 再 次 是 装饰 模式 ， 事 件 的 包装 、 处 理 者 功能 的 强 
化 都 会 用 到 装饰 模式 。 当 然 了 ， 我 们 还 可 能 用 到 其 他 的 模式 ， 只 要 能 够 
很 好 地 解决 我 们 的 困境 ， 那 就 好 好 使 用 吧 ， 这 也 是 我 们 学 习 设计 模式 的 
目的 。 





第 五 部 分 扩展 篇 
第 37 章 MVC 框 架 


第 38 半 ”新 模式 


第 37 章 ”MVC 框 架 


37.1 MVC 框 架 的 实现 


相信 这 本 书 的 读者 对 Struts 的 使 用 是 得 心 应 手 了 ， 也 明白 MVC 框 架 
有 诸如 视图 与 逻辑 解 厢 、 灵 活 稳 定 、 业 务 逻 辑 可 重用 等 优点 ， 而 且 还 对 
其 他 的 MVC 框 架 ( 例 如 JSF、Spring MVC、WebWork) 也 了 解 一 点 。 
SSH 〈Struts+Spring+Hibernate) 框架 是 Java 项 目 和 常用 的 框架 ， 作 为 一 个 
Java 开 发 人 员 ， 应 该 对 SSH 框 架 很 熟悉 了 ! 我 们 今天 就 学 Struts 怎 么 用 ! 
我 们 要 讲 的 是 MVC 框 架 如 何 设 计 ， 你 可 以 设计 一 个 新 的 MVC 框 架 与 


Struts 抗 衡 。 


在 开始 设计 MVC 框 架 前 ， 首 先 要 对 MVC 框 架 做 一 个 简单 的 介绍 。 
MVC (Model ViewController) 的 中 文 名 称 叫 做 模型 视图 控制 器 模型 ， 
就 是 因为 它 的 英文 名 字 太 流行 了 ， 中 文 名 字 反 而 被 忽略 了 。 它 诞生 于 20 
世纪 80 年 代 ， 原 本 是 为 桌面 应 用 程序 建立 起 来 的 一 个 框架 ， 现 在 反而 在 
Web 应 用 中 大 放 异 彩 (其实 也 可 以 把 B/S 认为 是 C/S 的 瘦 化 结构 )，MVC 
框架 的 目的 是 通过 控制 器 C 将 模型 M (代表 的 是 业务 数据 和 业务 逻辑 ) 
和 视图 Y〈 人 机 交互 的 界面 ) 实现 代码 分 离 ， 从 而 使 同一 个 逻辑 或 行为 
或 数据 可 以 具有 不 同 的 表现 形式 ， 或 者 是 同样 的 应 用 逻辑 共享 相同 、 不 
同 视图 。 比 如 ， 可 以 用 下 浏览 器 访问 菜 应 用 网 站 页面 格式 遵守 HTML 











标准 ) ， 也 可 以 用 手机 通过 WAP 浏 览 器 访问 页面 格 式 遵 守 WML 格 
式 ) ， 对 MVC 框 架 来 说 ， 后 台 的 程序 〈 也 就 是 模型 ) 不 用 做 任何 修 





改 ， 只 是 使 用 的 视图 不 同 而 已 。MVC 框 架 如 图 37-1 所 示 。 


控制 妖 


(Controller) 





图 37-1 MVC 框 架 示意 图 


该 框架 是 Model2 的 结构 。MVC 框 架 有 两 个 版 本 ， 一 个 是 Model1， 
也 就 是 MVC 的 第 一 个 版 本 ， 它 的 视图 中 存在 着 大 量 的 流程 控制 和 代码 
开发 ， 也 就 是 控制 器 和 视图 还 具有 部 分 的 耦合 。 也 有 人 不 认为 Modell 属 
于 MVC 框 架 ， 那 也 说 得 通 ， 因 为 在 JSP 页 面 中 融合 了 控制 器 和 视图 的 功 
能 ， 这 其 实 就 是 早期 的 开发 模式 ， 开 发 一 堆 的 JSP 页 面 ， 然 后 再 开发 一 
堆 的 JavaBean，JavaBean 就 是 模型 了 ， 它 只 是 把 JSP 和 JavaBean 拆 分 开 
了 。Model2 版 本 则 提倡 视图 和 模型 的 彻底 分 离 ， 视 图 仅仅 负责 展示 服 
务 ， 不 再 参与 业务 的 行为 和 数据 处 理 。 我 们 举例 来 说 明 MVC 框 架 是 如 

















何 图 37-1 MVC 框 架 示 意图 控制 器 (Controller) 视图 (View) 模型 


(Model) 第 37 章 运行 的 。 


在 做 Web 开 发 时 ， 例 如 开发 一 个 数据 展示 界面 ， 从 一 张 表 中 把 数据 
全 部 读 出 ， 然 后 展示 到 页 面 上 ， 也 是 一 个 简单 的 表格 ， 其 中 页 面 展 示 的 
格式 就 是 视图 V， 怎 么 从 数据 库 中 取得 数据 则 是 模型 M， 那 控制 器 C 是 
做 什么 的 呢 ? 它 负责 把 接收 的 浏览 器 的 请 求 转发 通知 模型 M 处 理 ， 然 后 
组 合 视图 V， 最 终 反 馈 一 个 带 数 据 的 视图 到 用 户 端 ， 数 据 处 理 流程 如 图 
37-2 所 示 。 








返回 训 览 右 @ 训 览 右 请 求 数 据 @ 


控制 器 
(Controller ) 
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图 37-2 MVC 框 架 的 逻辑 流 


浏览 器 通过 HTTP 协 议 发 出 数据 请 求 山 ， 由 控制 右 接 收 请 求 ， 通 过 
路 径 书 委托 给 数据 模型 处 理 ， 模 型 通过 与 逻辑 层 和 持久 层 的 交互 (路 径 
4)) ， 把 处 理 结 果 反 饿 给 控制 器 《路 径 回 ) ， 控 制 器 根据 结果 组 闭 视 
图 (路径) ， 并 最 终 反 馈 给 浏览 器 可 以 接受 的 HTML 数 据 《〈 路 径 
(@) 。 整 体 MVC 框 架 还 是 比较 简单 的 ， 但 它 带 来 的 优点 非常 多 。 


e 总 重用 性 





一 个 模型 可 以 有 多 个 视图 ， 比 如 同样 是 一 批 数 据 ， 可 以 是 柱状 展 
示 ， 也 可 以 是 条 形 展示 ， 还 可 以 是 波形 展示 。 同 样 ， 多 个 模型 也 可 以 共 
有 一 个 视图 ， 同 样 是 一 个 登录 界面 ， 不 同 用 户 看 到 的 菜单 数量 《模型 中 
的 数据 〉 不 同 ， 或 者 不 同业 务 权 限 级 别 的 用 户 在 同一 个 视图 中 展示 。 














。 低 耦 合 


因为 模型 和 视图 分 离 ， 两 者 没有 耦合 关系 ， 所 以 可 以 独立 地 扩展 和 
修改 而 不 会 产生 相互 有 影响。 


e 快速 开 及 和 便捷 部 车 


模型 和 视图 分 离 ， 可 以 使 各 个 开发 人 员 上 自由 发 挥 ， 做 视图 的 人 员 和 
开发 模型 的 人 员 可 以 制订 目 己 的 计划 ， 然 后 在 控制 器 的 协作 下 实现 完整 
的 应 用 逻辑 。 





MVC 框 架 还 有 很 多 优点 ， 本 章 主要 不 是 讲解 MVC 技 术 ， 主 要 是 通 
过 讲解 设计 MVC 框 架 来 说 明 设计 模式 该 怎么 应 用 ， 所 以 想 了 解 更 详细 
的 MVC 框 架 信息 请 自行 查阅 资料 。 








37.1.1 MVC 的 系统 架构 


我 们 设计 的 MVC 框 架 包 含 以 下 模块 :核心 控制 器 
(FilterDispatcher〉 、 拦 截 器 〈Interceptor) 、 过 滤器 (Filter) 、 模 型 管 
理 器 〈Model Action) 、 视 图 管理 器 (View Provider) 等 ， 基 本 上 一 个 
MVC 框 染 上 和 营 用 的 功能 我 们 部 具备 了 ， 系 统 染 构 如 图 37-3 所 示 。 


核心 控制 右 


人 和 和 天 人 管理 
构 


图 37-3 MVC 系 统 架 松 











各 个 模块 的 职责 如 下 : 
e 核心 控制 露 


MVC 框 架 的 入 口 ， 负 贡 接 收 和 反馈 HTTP 请 求 。 


e@ 过 滤器 


Servlet 容 需 内 的 过 滤 顺 ， 实 现 对 数据 的 过 滤 处 理 。 由 于 它 是 容器 内 
的 ， 因 此 必须 依 徘 容 笑 才能 运行 ， 它 是 容 右 的 一 项 功能 ， 与 容 莫 居 恩 相 
天， 本 章 就 不 详细 讲述 了 。 


e 拦截 器 


对 进出 模型 的 数据 进行 过 滤 ， 它 不 依赖 系统 容器 ， 只 过 小 MVC 框 
架 内 的 业务 数据 。 


e 模型 管理 器 


提供 一 个 模型 框架 ， 该 框架 内 的 所 有 业务 操作 都 应 该 是 无 状态 的 ， 
不 关心 容器 对 象 ， 例 如 Session、 线 程 池 等 。 


e 视图 管理 器 
管理 所 有 的 视图 ， 例 如 提供 多 语言 的 视图 等 。 
e 辅助 工具 
它 其 实 就 是 一 大 堆 的 辅助 管理 工具 ， 比 如 文件 管理 、 对 象 管理 等 。 


在 我 们 的 MVC 框 洪 中 ， 核 心 控制 器 是 最 重要 的 ， 我 们 就 先 从 它 痢 
手 。 核 心 控制 器 使 用 了 Servlet 容 费 的 过 小 器 搁 术 ， 需 要 编写 一 个 过 滤 


器 ， 所 有 进入 MVC 框 架 的 请 求 都 需要 经 过 核心 控制 器 的 转发 ， 类 图 如 
图 37-4 所 示 。 









Value Manager 
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+String getViewPath() 


IActionDispatcher 
| 
+String actionInovke() 





> Ac TI a 忆 
视图 管理 需 






Value Stack Helper 
+void putIntoValueStack() 


图 37-4 核心 控制 器 类 图 





+void debug(String log) 
+void info(String log) 





由 于 类 图 中 的 部 分 输入 参数 类 型 较 长 ， 省 略 了， 请 读者 仔细 看 代 
人 码 。 首 先 阅 读 FilterDispatcher 代 码 ， 如 代码 清单 37-1 所 示 。 


代码 清单 37-1 核心 控制 器 


public class FilterDispatcher implements Filter { 
// 定 义 一 个 值 栈 辅助 类 
private ValueStackHelper valueStackHelper = new ValueStackHe 
// 应 用 IActionDispatcher 
IActionDispather actionDispatcher = new ActionDispatcher(); 
//servlet 销 毁 时 要 做 的 事情 
public void destroy() { 




















} 

// 过 滤器 必须 实现 的 方法 

public void doFilter(ServletRequest request, ServletResponse 
FilterChain chain) throws IOException, ServletException 
// 转 换 为 HttpServletRequest 
HttpServletRequest req = (HttpServletRequest)request; 
HttpServletResponse res = (HttpServletResponse)response 

















// 传 递 到 其 他 过 滤器 处 理 
chain.doFilter(req, res); 

// 获 得 从 HTTP 请 求 的 ACTION 名 称 

String actionName = getActionNameFromURI(redq); 

// 对 ViewManager 的 应 用 

ViewManager viewManager = new ViewManager(actionName); 
// 所 有 参数 放 入 值 栈 

ValueStack valueStack = valueStackHelper.putIntoStack(r 
// 把 所 有 的 请 求 传递 给 ActionDispatcher 处 理 
String result =actionDispatcher.actionInvoke(actionName 
String viewPath = viewManager .getViewPpath(result); 
// 直 接 转 向 

RequestDispatcher rd = red,.getReduestDispatcher(ViewPat 
rd.forward(req, res); 






































public void init(FilterConfig arg0) throws ServletException 
/* 











* 414、 检查 XML 配 置 文件 是 否 正确 
* 2、 启 动 监控 程序 ， 观 察 配置 文件 是 否 正 确 
*/ 



































// 通 过 ur1 获 得 actionName 

private String getActionNameFromURI(HttpServletRequest red){ 
String path = (String) req.getRequestURI(); 
String actionName = path.substring(path.1lastIindexof("/" 
path.lastIindexOof(".")); 
return actionName; 


我 们 按照 系统 的 执行 顺序 来 讲解 ， 首 先 在 容 右 的 配置 文件 中 需要 配 
置 该 过 滤器 ， 以 tomcat 为 例 ， 配 置 如 代码 清单 37-2 所 示 。 





代码 清单 37-2 核心 控制 器 的 配置 


<?xml1 version="1.0" encoding="UTF-8"?> 

<web-app> 

<filter> 
<display-name>FilterDispatcher</display-name> 
<filter-name>FilterDispatcher</filter-name> 
<filter-class>{ 包 名 }.FilterDispatcher</filter-class> 

</filter> 

<filter-mapping> 
<filter-name>FilterDispatcher</filter-name> 


<url-pattern>*.do</url-pattern> 
</filter-mapping> 
</web-app> 





在 这 里 定义 了 对 所 有 以 .do 结尾 的 请 求 进行 拦截 ， 拦 截 后 由 
FilterDispatcher 的 doFilter 方 法 处 理 。 过 小 占 是 在 启动 时 自动 初始 化 ， 初 
始 化 完毕 后 立刻 调用 inti 方 法 ， 在 init 方 法 中 我 们 做 了 两 件 事情 。 











e 检查 XML 配置 文件 


所 有 的 Action 与 视图 的 对 应 关系 是 在 配置 文件 中 配置 的 ， 因 此 厦 配 
置 文件 出 错 ， 该 应 用 应 该 停止 响应 ， 这 就 需要 在 启动 时 对 XML 文件 进 
行 完 整 性 检查 和 语法 分 析 。 














e 月 动 监视 需 





配置 文件 随时 都 可 以 修改 ， 但 是 它 修改 后 不 应 该 需要 重新 局 动 应 用 
才能 生效 ， 否 则 对 系统 的 正常 运行 有 非常 大 的 影响 ， 因 此 这 里 要 使 用 到 
Listener 〈 监 听 ) 行为 了 。 











init 方 法 需要 做 的 这 两 件 事情 是 非常 重要 的 ， 而 且 都 还 包含 了 几 种 
不 同 的 设计 模式 。 首 先 我 们 来 看 检查 XML 配 置 文 件 如 何 实现 。 先 看 我 
们 定义 的 XML 格 式 〈 框 架 中 应 该 定义 一 个 DTD 文 件 ，XML 文 件 的 模 
板 ， 读 者 可 以 自行 实现 ) ， 如 代码 清单 37-3 所 示 。 


代码 清单 37-3 XML 配置 文件 


<?xml] version="1.0" encoding="UTF-8"?> 
<mvc> 
<action name="1oginAction" class="{ 类 名 全 路 径 y" method="execut 
<result name="success">/index2.]jsp</result> 
<result name="fail">/index.jsp</result> 
</action> 
</mvc> 


读者 思考 一 下 该 怎么 检查 这 个 XML 文 件 ， 有 两 个 不 同 的 检查 策 
略 : 一 是 检查 XML 文件 的 语法 是 否 正确 ;二 是 框架 逻辑 检查 ， 这 是 什 
么 意思 呢 ? 比如 我 们 在 XML 文件 中 配置 了 一 个 类 A， 它 只 有 一 个 方法 
methodA， 在 method 中 编写 的 配置 文件 为 method="methoda"， 方 法 名 写 
错 了 ， 那 这 样 的 配置 是 肯定 不 能 运行 的 ， 需 要 框架 逻辑 检查 把 它 揪 出 
来 。 这 两 种 不 同 的 算法 是 完全 可 以 蔡 换 的 ， 而 且 很 有 必要 替换 ， 逻 辑 检 
查 在 应 用 启动 的 时 候 需要 对 所 有 的 类 进行 过 滤 处 理 ， 牺 牲 的 是 效率 ， 这 
在 测试 机 上 没有 问题 ， 在 生产 机 上 要 花 20 分 钟 才 能 把 一 个 应 用 启动 起 
来 ， 在 分 秒 必 和 争 的 业务 系统 中 这 是 不 允许 的 ， 因 此 就 要 求 该 算法 可 以 退 
休 ， 想 用 的 时 候 (测试 机 环境 就 用 ， 不 想 用 的 时 候 〈 生 产 环 境 ) 就 不 
用 ， 想 到 什么 模式 了 吗 ? 策略 模式 ， 这 两 个 算法 都 是 对 同样 的 源 文件 进 
行 检查 ， 只 是 算法 不 同 ， 当 然 可 以 相互 蔡 换 了 。 类 图 比较 简单 ， 就 不 再 
画 了 ， 我 们 直接 看 代码 ， 抽 象 策略 如 代码 清单 37-4 所 示 。 

















代码 清单 37-4 XML 文件 校 验 


public interface IXmlValidate { 
// 只 有 一 个 方法 ， 检 查 XML 是 否 符 合 条 件 
public boolean validate(String xmlPath); 








根据 一 个 指定 的 路 径 ， 对 XML 进行 校 验 ， 返 回 校 验 结果 。 普 通 
XML 校 验 如 代码 清单 37-5 所 示 。 


代码 清单 37-5 普通 XML 校 验 


public class CommonxmlValidate implements IXmlValidate { 
//XML 语 法 检查 ， 比 如 是 否 少 写 了 一 个 结束 标志 
public boolean validate(String xmlPath) { 
return false; 
} 








由 于 读 写 XML 文 件 一 般 使 用 DOM4J 或 者 JDOM， 都 提供 对 XML 文 
件 的 语法 校 验 功 能 ， 不 符合 XML 语 法 (比如 一 个 节点 少 写 了 结束 标志 
</node) 的 文件 是 不 能 解析 的 ， 读 者 可 以 在 自己 编写 框架 时 使 用 该 类 型 
工具 。 


框架 的 逻辑 算法 如 代码 清单 37-6 所 示 。 


代码 清单 37-6 框架 逻辑 校 验 


public class LogicxmlValidate implements IXmlValidate { 
// 检 查 xmlPath 是 否 符合 逻辑 ， 比 如 不 会 出 现 一 个 类 中 没有 的 方法 
public boolean validate(String xmlPath) { 
return false; 
} 














逻辑 校 验 相对 比较 复杂 ， 它 的 逻辑 流程 如 下 : 


e 读 取 XML 文件 。 


e 使 用 反射 技术 初始 化 一 个 对 象 《配置 文件 中 的 class 属 性 值 ) 。 








e 检查 是 否 存 在 配置 文件 中 配置 的 方法 。 
e 检查 方法 的 返回 值 是 否 是 String， 并 且 无 输入 参数 ， 同 时 必须 继 
承 指定 类 或 接口 。 


逻辑 校 验 需要 把 所 有 的 对 象 都 初始 化 一 所 ， 在 Action 类 较 多 的 情况 
下 ， 效 率 较 低 ， 但 它 可 以 提前 发 现 出 现 访 问 寞 党 的 情况 ， 把 问题 解决 在 
彰 节 状态 。 我 们 继续 来 看 两 个 集 略 的 场景 类 ， 如 代码 清单 37-7 所 示 。 





代码 清单 37-7 策略 的 场景 类 


public class Checker { 
// 使 用 哪 一 个 策略 
private IXmlValidate validate; 














//xml 配 置 文件 的 路 径 

String xmlPath; 

// 构 造 函 数 传递 

public Checker(IXmlValidate _validate)t{ 
this.validate = validate; 


} 
public void setxmlPath(String _xmlPath)t{ 
this.xmlPath = _xmlPath; 


} 
// 检 查 
public boolean check(){ 
return validate.validate(xmlPath); 
} 





与 通用 策略 模式 稍 有 不 同 ， 每 个 模式 在 实际 应 用 环境 中 都 有 其 个 
性 ， 很 少 出 现 完全 照搬 一 个 模式 的 情况 ， 灵 活 应 用 设计 模式 才 是 关键 。 


在 FilterDispatcher 的 init 方 法 中 ， 我 们 刚刚 说 它 有 两 个 职员 : 第 一 个 
职责 是 XML 文 件 校 验 ， 这 个 我 们 完成 了 ; 第 二 个 职责 是 启动 监控 程 
序 。 问 题 是 要 监控 什么 呢 ? 监控 XML 有 没有 被 修改 ， 如 果 修 改 了 就 立 
刻 通 知 校 验 程序 对 它 进行 校 验 。 这 就 又 用 到 了 观察 者 模式 ， 发 现 文件 被 
修改 ， 它 立刻 通知 检查 者 处 理 ， 该 片段 的 类 图 如 图 37-5 所 示 。 








+vold update() 





图 37-5 XML 文件 监控 类 图 


为 什么 要 在 这 里 定义 一 个 Watchable 接 口 昵 ? 它 表 示 所 有 可 以 监视 
的 资源 ， 比 如 数据 库 、 日 志文 件 、 磁 盘 空 间 等。 我 们 来 看 代码 ， 监 听 接 
口 如 代码 清单 37-8 所 示 。 


代码 清单 37-8 监听 接口 


public interface WatchabJle { 
// 监 听 
public void watch( ) ; 


文件 监听 者 是 观察 者 模式 的 被 观察 者 ， 它 一 旦 发 现 文件 发 生变 化 立 
刻 通知 观察 者 ， 如 代码 清单 37-9 所 示 。 


代码 清单 37-9 文件 监听 者 


public class Filewatcher extends Observable implements Watchablet{ 
// 是 否 要 重新 加 载 XML 文 件 
private boolean isReload = false; 
// 启 动 监视 
public void watch(){ 
// 局 动 一 个 线程 ， 每 隔 15 秒 扫描 一 下 文件 ， 发 现 文件 日 期 被 修改 ， 立 刻 通 久 
Super ,addobserver(new Checker()); 
super.setChanged( ); 
super.notifyObservers(isReload); 




















由 于 框架 是 在 操作 系统 之 上 运行 的 ， 文 件 变 化 时 操作 系统 是 不 会 通 
知 应 用 系统 的 ， 因 此 我 们 能 做 的 就 是 局 动 一 个 线程 监视 一 批文 件 ， 发 现 
文件 改变 了 ， 立 刻 通知 相关 的 处 理 者 ， 它 虽然 有 时 间 延 人 运 ， 但 对 于 一 个 
应 用 框架 来 说 是 非常 有 必要 的 ， 避 人 免 了 重 局 应 用 才能 使 配置 生效 的 情 











检查 一 个 文件 的 时 间 一 般 是 蝇 秒 级 的 ， 相 对 于 我 们 设置 的 运行 周期 
《比如 15 秘 执行 一 次 ) 是 一 个 非常 微小 的 运行 时 间 ， 对 应 用 不 会 产生 任 
何 影响 。 大 家 都 在 使 用 Log4j 进 行 日 志 处 理 ， 它 有 一 个 线程 是 每 5 秒 检查 


一 次 日 志 是 人 否 满 ， 大 家 觉得 性 能 受 影 响 了 吗 ? 基本 上 性 能 影响 可 以 忽略 








不 计 ; 





由 于 Checker 还 要 作为 观察 者 ， 因 此 它 要 实现 Observer 接口 ， 同 时 实 
现 update 方 法 ， 如 代码 清单 37-10 所 示 。 


代码 清单 37-10 修正 后 的 检查 者 


public class Checker implements Observert{ 
public void update(Observable arg0, Object arg1) { 
// 检 查 是 否 符 合 条 件 
arg1 = check(); 





到 此 为 止 ， 我 们 把 init 方 法 已 经 讲解 完毕 ， 它 是 在 容器 初始 化 时 调 
用 。 有 一 个 HTTP 请 求 发 送 过 来 ， 容 器 调用 我 们 编写 的 doFilter 方 法 。 仔 
细 看 一 下 我 们 的 代码 ， 其 中 有 这 样 一 句 话 : Chain.doFilter(req,res)， 这 人 句 
话 是 什么 意思 呢 ? 是 说 让 后 续 的 过 滤器 先 运行 ， 等 它们 运行 完毕 后 该 过 
滤 堪 再 运行 ， 应 该 想到 这 是 一 个 贡 任 链 模式 ， 它 的 类 型 是 FilterChain 。 
Servlet 容 器 把 所 有 的 过 滤器 组 合 在 一 起 形成 了 一 个 过 滤器 链 ， 它 是 怎么 
做 到 的 呢 ? 容器 启动 的 时 候 ， 把 所 有 的 过 滤器 都 初始 化 完毕 ， 然 后 根据 
它们 在 web.xml 中 的 配置 顺序 ， 从 上 向 下 组 装 一 个 过 滤器 链 。 注 意 所 有 
的 过 滤器 都 必须 实现 Filter 接 口 ， 这 是 建立 过 滤 才 链 的 首要 前 提 。 











我 们 再 回 过 头 来 仔细 看 看 类 图 ， 是 不 是 有 氮 熟悉 ? 对 ， 类 似 于 中 介 
者 模式 ， 我 们 并 没有 把 中 介 者 传递 到 各 个 同事 类 ， 只 是 我 们 采用 中 介 者 
模式 的 思想 ， 把 中 介 者 的 职 贡 分 发 出 去 由 各 个 同事 类 来 处 理 。 





37.1.2 模型 管理 器 


模型 管理 器 是 整个 MVC 框 架 的 难点 ， 在 这 里 我 们 会 看 到 非常 多 的 
设计 模式 。 我 们 在 核心 控制 器 的 类 图 中 看 到 有 一 个 IActionDispatcher 接 
口 ， 它 实现 的 模型 行为 分 发 是 一 个 门面 模式 ， 如 代码 清单 37-11 所 示 。 


代码 清单 37-11 模型 行为 分 发 接口 


public interface IActionDispather { 
// 根 据 Action 的 名 字 ， 返 回 处 理 结果 
public String actionInvoke(String actionName ) ; 























它 的 职责 非常 简单 ， 得 到 actionName 就 执行 ， 熟 悉 Struts 的 读者 可 能 
很 清楚 这 个 方法 是 非常 复杂 的 ， 它 要 从 配置 文件 中 找到 执行 对 象 ， 然 后 
执行 方法 ， 还 要 考虑 值 栈 、 异 常 等 ， 非 常 复杂 。 我 们 这 里 就 有 一 个 方 
法 ， 它 对 外 提供 一 个 门面 ， 所 有 的 访问 都 是 通过 该 门面 来 完成 ， 其 实现 
类 如 代码 清单 37-12 所 示 。 














代码 清单 37-12 模型 分 发 实现 


public class ActionDispather implements IActionDispather { 
// 需 要 执行 的 Action 
private ActionManager actionManager = new ActionManager(); 
// 拦 截 器 链 
private ArrayList<Interceptors> listIinterceptors = Intercept 
public String actionInvoke(String actionName) { 
// 前 置 拦截 器 
return actionManager .execAction(actionName ) 


// 后 置 拦截 器 





它 是 一 个 非常 简单 的 类 ， 对 外 部 提供 统一 封装 好 的 行为 。 模 型 管理 
器 的 类 图 如 图 37-6 所 示 。 


首先 说 ActionManager 类 ， 它 负责 管理 所 有 的 行为 类 Action， 那 就 必 
须 定 义 一 个 行为 类 的 接口 或 抽象 类 ， 如 代码 清单 37-13 所 示 。 


代码 清单 37-13 抽象 Action 


public abstract class ActionSupport { 
public final static String SUCCESS = "success"; 
public final static String FAIL = "fail"; 
// 默 认 的 执行 方法 
public String execute(){ 
return SUCCESS; 
} 
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图 37-6 模型 管理 器 类 图 


抽象 的 ActionSupport 类 看 起 来 很 简单 ， 其 实 它 可 不 简单 ， 所 有 的 模 
型 行为 都 继承 该 类 ， 它 之 所 以 提供 一 个 默认 的 execute 方 法 ， 是 因为 在 
xml 的 配置 文件 中 ， 可 以 省 略 掉 method="XXX" 这 句 话 ， 默 认 就 是 调用 该 
方法 。 它 还 有 一 个 非常 重要 的 行为 : 对 象 映射 ， 把 HTTP 传 递 过 来 的 字 
符 串 映射 到 一 个 业务 对 象 上 ， 我 们 会 在 值 栈 中 详细 讲解 。 








读者 可 能 很 疑惑 ，Action 的 操作 是 需要 获得 环境 数据 的 ， 比 如 
HTTPServletRequest 的 数据 ， 还 有 系统 中 的 Session 数 据 ， 单 单一 个 
ActionManager 如 何 获得 这 些 数据 呢 ? 通 过 值 栈 ， 在 值 栈 中 保存 着 该 
Action 需 要 的 所 有 数据 。 


我 们 再 来 看 ActionManager 类 ， 如 代码 清单 37-14 所 示 。 


代码 清单 37-14 Action 管 理 类 


public class ActionManager { 
// 执 行 Action 的 指定 方法 
public String execAction(String actionName){ 
return null; 
} 








就 这 么 简单 吗 ? 非 也 ， 其 中 的 参数 actionName 指 xml 配 置 中 的 name 
属性 值 ， 它 与 从 HTTP 传 递 过 来 的 请 求 对 象 是 一 臻 的， 根据 HTTP 传 递 过 
来 的 actionName 在 xml 文 件 中 查找 对 应 的 节点 (Node) ,然后 就 可 以 获取 











到 该 类 的 名 称 和 方法 ， 通 过 动态 代理 的 方式 执行 该 方法 ， 在 这 里 我 们 使 
用 到 了 代理 模式 。 


有 读者 可 能 听 说 过 反射 是 影 啊 性 能 的 ， 它 提供 解释 型 操作 。 是 这 样 
的 ， 但 是 实际 应 用 还 没有 这 么 高 的 要 求 ， 把 数据 库 设 计 得 优秀 一 点 ， 系 
统 染 构 多 考虑 一 点 ， 提 升 的 性 能 远 比 这 个 多 。 





然后 我 们 再 来 看 拦截 器 ， 拦 截 器 和 过 滤器 的 区 别 就 是 : 拦截 器 可 以 
脱离 容器 〈J2EE 容 器 ) 运行 ， 而 过 滤器 不 行 。 拦 截 器 的 目的 是 对 数据 和 
行为 进行 过 滤 ， 符 合 条 件 的 才 可 以 执行 Action， 或 者 是 在 Action 执 行 完 
毕 后 ， 调 用 拦截 器 进行 回收 处 理 。 我 们 定义 一 个 抽象 的 拦截 器 ， 如 代码 
清单 37-15 所 示 。 


代码 清单 37-15 抽象 拦截 器 


public abstract class AbstractInterceptor { 
// 获 得 当前 的 值 栈 
private ValueStack valueStack = ValueStackHelper ,getValueSta 
// 拦 截 器 类 型 : 前 置 、 后 置 、 环 绕 
private int type =0; 
// 当 前 的 值 栈 
protected ValueStack getValueStack(){ 
return ValueStack 


} 
// 拦 截 处 理 
public final void exec(){ 

// 根 据 type 不 同 ， 处 理 方式 也 不 同 


} 

// 拦 截 器 类 型 

protected abstract void setType(int type); 
// 子 类 实现 的 拦截 器 

protected abstract void intercept(); 












































这 怎么 和 Struts 的 拦截 器 不 相同 呀 ! 是 的 ，Struts 的 拦截 器 的 拦截 方 
法 intercept 是 要 接收 一 个 ActionInvocation 对 象 ， 这 里 却 没有 ， 我 们 主要 
是 讲解 模式 ， 是 为 了 技术 实现 ， 而 类 似 Struts 的 MVC 框 架 属 于 工业 级 别 
的 应 用 框架 ， 考 虑 了 太 多 的 外 界 因素 。 拦 截 器 分 为 三 种 。 


e 前 置 拦截 器 





在 Action 调 用 前 执行 ， 对 Action 需 要 的 场景 数据 进行 过 滤 或 重 构 。 
e 后 置 拦截 器 


在 Action 调 用 后 执行 ， 负 责 回 收场 景 ， 或 对 Action 的 后 续 事 务 进行 
处 理 。 

e 环绕 拦 稚 器 

在 Action 调 用 前 后 都 执行 。 

我 们 的 框架 在 这 里 使 用 了 一 个 模板 方法 模式 ， 开 发 者 继承 
AbstractInterceptor 后 ， 只 要 完成 两 个 职责 即 可 : 定义 拦截 类 型 


CsetType) 和 实现 拦截 器 要 拦截 的 方法 〈intercept) ， 不 用 考虑 它 到 底 
如 何 调用 ActionInvocation， 相 对 来 说 简单 又 实用 。 








有 拦截 器 就 肯定 有 拦截 器 链 ， 多 个 拦截 器 组 合 在 一 起 就 成 了 拦截 右 
链 ， 如 代码 清单 37-16 所 示 。 


代码 清单 37-16 拦截 器 链 


public class Interceptors implements Iterable<AbstractIinterceptor 
// 根 据 拦截 器 列表 建立 一 个 拦截 器 链 


public Interceptors(ArrayList<AbstractInterceptor> list){ 


} 

// 列 出 所 有 的 拦截 器 

public Iterator<AbstractInterceptor> iterator() { 
return null; 


} 

// 拦 截 器 链 的 执行 方法 
public void intercept(){ 
// 委 托 拦截 器 执行 

} 











它 实 现 了 Iterable 接 口 ， 提 供 了 一 个 方便 遍历 拦截 器 的 方法 ， 这 是 迭 
代 器 模式 。 同 时 ， 由 于 是 一 个 链 结构 ， 我 们 就 想到 了 责任 链 ， 这 里 确实 
也 是 一 个 贡 任 链 模式 ， 只 是 核心 控制 器 上 的 过 滤 链 是 Servlet 容 右上 自己 实 
现 的 ， 而 拦截 器 链 则 需要 我 们 自己 编码 实现 。 代 码 不 复杂 ， 读 者 可 以 参 
考 责任 链 章节 





还 有 两 个 很 有 意思 的 方法 。 我 们 来 看 构造 函数 ， 筷 通过 一 个 容 
纳 有 拦截 右 的 动态 数组 生成 一 个 拦截 器 链 ， 它 是 一 个 目 激 行为 ， 在 
XML 文件 中 配置 一 个 拦截 器 ， 其 中 包含 多 个 拦截 器 ， 我 们 的 构造 函数 
就 是 这 样 的 用 途 ， 目 己 建 立 一 条 链 ， 而 不 是 父 类 或 者 高 层 模块 。 再 看 
intercept 方 法 ， 链 中 每 个 节点 都 是 一 个 拦截 器 ， 都 有 一 个 intercept 方 法 ， 
拦截 需 链 中 的 intercept 方 法 行为 是 委托 第 一 个 节点 拦截 右 的 intercept 方 
法 ， 然 后 所 有 的 拦截 需 都 会 按照 顺序 执行 一 忆 ， 这 一 点 和 我 们 的 贡 任 链 
模式 是 不 同 的 ， 员 任 链 模式 是 只 要 有 节 扣 处 理 束 可 以 认为 是 结束 ， 后 续 











节点 可 以 不 再 参与 处 理 。 


Struts 还 实现 了 方法 拦截 器 ， 只 要 继承 MethodFilterInterceptor 即 可 ， 
主要 使 用 了 反射 技术 ， 有 兴趣 的 话 可 以 看 看 源 代 码 。 注 意 我 们 这 里 使 用 
了 拦截 器 链 而 不 像 Struts 那 样 是 拦截 器 栈 ， 一 字 之 差 ， 系 统 设计 差别 可 
就 大 了 。 








注意 拦截 器 是 会 影响 系统 性 能 的 ， 所 有 的 Action 在 执行 前 后 都 会 
被 拦截 器 过 滤 一 过 ， 即 使 不 符合 拦截 条 件 的 也 会 被 检查 一 忆 ， 所 以 非 必 
要 情况 不 要 使 用 拦截 器 。 





由 于 在 XML 配置 文档 中 有 太 多 的 拦截 融 链 ， 因 此 需要 有 一 个 工矿 
来 创建 它 ， 和 否则 太 烦琐 。 如 代码 清单 37-17 所 示 。 





代码 清单 37-17 拦截 器 链 工 厂 


public class InterceptorFactory { 
public static ArrayList<Interceptors> createInterceptors(){ 
// 根 据 配置 文件 创建 出 所 有 的 拦截 器 链 


return null; 








} 





它 的 作用 是 根据 配置 文件 一 次 性 地 创建 出 所 有 的 拦截 右 ， 很 简单 的 
工厂 方法 模式 。 如 果 读 者 还 记得 我 们 刚刚 讲 的 配置 文件 更 新 问题 的 话 ， 
应 该 想到 这 里 也 应 该 有 一 个 观察 者 ， 配 置 文件 修改 了 ， 拦 截 器 链 当然 也 


要 重建 了 ， 确 实 应 该 有 这 样 一 个 观察 者 ， 读 者 可 以 自行 思考 如 何 实现 。 


37.1.3 值 栈 


值 栈 按 道理 说 应 该 很 简单 ， 束 是 把 HTTP 传 递 过 来 的 String 字 符 串 压 
到 堆栈 中 。 听 起 来 很 简单 ， 实 现 起 来 就 比较 有 难度 了 ， 它 要 完成 两 个 职 


主 . 
内。 





e 管理 堆栈 








不 仅仅 是 出 栈 、 入 栈 这 么 简单 ， 它 要 管理 栈 中 数据 ， 同 时 还 要 允许 
前 置 拦截 器 对 栈 中 数据 进行 修改 ， 限 制 后 置 拦截 器 对 栈 的 修改 ， 还 要 把 
栈 中 数据 与 HTTPServletRequest 中 的 数据 建立 关联 。 








e 值 映射 


从 HTTP 传递 过 来 的 数据 都 是 字符 串 结 构 ， 那 怎么 才能 转化 成 一 个 
业务 对 象 呢 ? 比如 在 页 面 上 有 一 个 登录 框 ， 输 入 用 户 名 〈userName) 和 
密码 (password) 。 提 交 到 MVC 框 染 中 怎么 才能 转 为 一 个 User 对 象 呢 ? 
这 也 是 值 栈 要 完成 的 职 贡 。 


这 里 说 一 下 值 映 射 ， 怎 么 实现 一 个 值 的 映射 ， 这 也 是 一 个 反射 操作 
的 结果 。 首 先是 HTTP 传 递 过 来 的 参数 名 称 中 要 明确 映射 到 哪 一 个 对 
象 ， 例 如 使 用 点 号 (.) 区 分 ， 点 号 前 是 对 象 名 称 ， 点 号 后 是 属性 名 ， 如 此 








规定 后 就 可 以 轻松 地 人 处理 了 。 由 于 使 用 的 模式 较 少 ， 这 里 束 不 再 痪 述 。 
读者 大 有 兴趣 可 以 考虑 使 用 一 些 开源 工具 ， 比 如 dozer 等 。 


37.1.4 视图 管理 器 


视图 管理 器 的 功能 很 单一 ， 按 照 模型 指定 的 要 求 返 回 视图 ， 在 这 里 
用 到 的 主要 模式 就 是 桥梁 模式 ， 如 果 大 家 做 过 多 语言 的 开发 束 非 第 清楚 
了 ， 比 如 一 个 外 部 网 站 ， 提 供 中 日 英 三 种 语言 版 本 ， 我 们 不 可 能 每 个 语 
言 都 写 一 套 页 面 吧 。 一 般 是 定义 一 个 语言 资源 文件 ， 然 后 视图 根据 不 同 
的 语言 环境 加 载 不 同 的 语言 。 我 们 先 来 说 视图 ， 它 包含 三 部 分 。 











e 静态 页 面 





比如 图 片 放 在 什么 地 方 ， 字 体 大 小 是 什么 样子 ， 末 单 应 该 放置 在 什 
么 地 方 ， 这 部 分 工作 是 由 前 侣 人 员 开 发 的 ， 不 涉及 业务 逻辑 和 业务 数 
据 。 





e 动态 页 面 元 素 











它 指 的 是 在 一 个 固定 场景 下 不 发 生变 化 但 在 异 构 场景 中 发 生变 化 的 
元 素 ， 其 中 语言 就 属于 动态 页 面 元 素 ， 还 有 为 使 用 不 同 浏览 器 而 开发 的 
代码 。 比 如 浏览 器 下 、Firefox、Chrome 等 ， 虽 然 基本 上 都 是 符合 
HTML， 但 是 还 有 一 些 细节 差异 ， 特 别 是 在 JavaScript 的 处 理 方面 ， 稍 不 











注意 就 可 能 产生 灾难 。 


e 动态 数据 





由 模型 产生 的 数据 ， 它 对 视图 来 说 是 结构 固定 ， 并 可 反复 加 载 。 








在 这 三 部 分 中 ， 静 态 页 面 是 完全 静态 的 ， 动 态 页 面 元 素 是 稍微 有 点 
动感 ， 动 态 数据 完全 是 多 变 的 〈 数 据 结 构 不 发 生变 化 ， 否 则 页 面 无 法 展 
现 ) 。 把 动态 数据 融入 到 静态 页 面 中 比较 容易 ， 己 经 在 配置 文件 中 指定 
要 把 模型 中 的 数据 放 到 哪个 页 面 中 ， 现 在 的 问题 是 怎么 把 动态 页 面 元 素 
融入 到 静态 页 面 中 。 静 态 页 面 有 很 多 ， 语 言 类 型 也 有 很 多 ， 上 怎么 融合 在 
一 起 提供 给 浏览 堪 访 问 呢 ? 














桥梁 模式 可 以 解决 用 什么 笔 〈 圆 珠 笔 、 铅 笔 ) 和 画 什 么 图 形 〈 圆 
形 、 方 形 ) 的 问题 ， 我 们 遇 到 的 问题 与 此 场景 类 似 。 先 看 类 图 ， 如 图 
37-7 所 示 。 






+String getViewPath(String result) 
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+AbsView(AbsLangData langData) +Map<String, String> getltems() 
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+AbsLangData getLangData() 


+void assemblel() 
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图 37-7 视图 与 语言 类 图 








大 家 还 记得 Struts 是 怎么 配置 多 语言 的 文件 吗 ? 我 们 采用 类 似 的 结 
构 ， 如 代码 清单 37-18 所 示 。 
代码 清单 37-18 资源 配置 文件 


title= 标 题 
menu= 菜 单 








瑞 文 配置 瑟 单 与 此 类 似 ， 它 的 结构 就 是 一 个 Map 类 型 ， 我 们 把 它 读 
入 到 Map 中 ， 抽 象 类 如 代码 清单 37-19 所 示 。 


代码 清单 37-19 抽象 语言 


public abstract class AbsLangData { 
// 获 得 所 有 的 动态 元 素 的 配置 项 
public abstract Map<String,String> getIitems(); 

















getItems 方 法 是 获得 一 种 语言 下 的 所 有 配置 。 我 们 来 看 中 文 语言 
包 ， 如 代码 清单 37-20 所 示 。 
代码 清单 37-20 中 文 语 言 


public class GBLangData extends AbsLangData { 
@Override 
public Map<String, String> getItems() { 


光大 





* Map 的 结构 为 : 
* key='title',，value=' 标 题 ' 
* key='menu'，value=' 菜 单 ' 
WA 
return null; 


英文 语言 如 代码 清单 37-21 所 示 。 


代码 清单 37-21 英文 语言 


public class ENLangData extends AbsLangData { 
@Override 
public Map<String, String> getItems() { 
/< 
* _ Map 结构 为 : 
* key="'title',value='title'; 
* key='menu', value="'menu' 
*/ 
return null; 





视图 分 为 两 种 类 图 ， 一 种 是 需要 直接 蔡 换 资源 文件 的 视图 ， 比 如 
JSP 文 件 ， 框 染 直 接 把 语言 包 中 的 资源 项 玲 换 挥 JSP 中 的 条 目 即 可 ， 把 
ftitle} 蔡 换 为 “标题 *”， 把 {menu} 蔡 换 为 “ 染 单 ， 蔡 换 后 存在 框架 的 缓存 
目录 中 ， 提 高 系统 的 访问 效率 。 另 一 种 视图 是 不 能 将 换 的 ， 比 如 SWF 文 
件 ， 它 的 资源 可 以 通过 类 似 HTTP 传 递 参数 的 形式 传递 ， 重 写 一 个 URL 
即 可 。 我 们 首先 来 看 抽象 视图 ， 如 代码 清单 37-22 所 示 。 








代码 清单 37-22 抽象 视图 


public abstract class AbsView { 
private AbsLangData langData; 
// 必 须 有 一 个 语言 文件 
public AbsView(AbsLangData _langData)t{ 
this.1langData = _langData; 





} 

// 获 得 当前 的 语言 

public AbsLangData getLangData( ){ 
return langData; 


} 
// 页 面 的 URL 路 径 


public String getURI(){ 
return null; 


} 
// 组 装 一 个 页 面 
public abstract void assemble(); 


JSP 视 图 是 需要 丛 换 资源 项 ， 如 代码 清单 37-23 所 示 。 


代码 清单 37-23 JSP 视 图 


public class JspView extends AbsView { 
// 传 递 语言 配置 
public JspView(AbsLangData _langData)t{ 
super(_langData); 














@Override 
public void assemble() { 
Map<String,String> langMap = getLangData( ).getIitems(); 
for(String key:langMap.keySet())t 
ya 


* 直接 蔡 换 文件 中 的 语言 条 目 
*/ 


SWFE 文 件 是 不 能 替换 的 ， 采 用 重 写 URE 的 方式 ， 如 代码 清单 37-24 
所 示 。 


代码 清单 37-24 SWF 视图 


public class SwfView extends AbsView { 
public SwfView(AbsLangData _langData)t{ 
super(_langData); 


@Override 

public void assemble() { 
Map<String,String> langMap = getLangData().getIitems(); 
for(String key:langMap.keySet())t 


/A/* 
* 组 装 一 个 HTTP 的 请 求 格式 : 
* http://abc.com/xxx.swf?key1l=value&key2=value 
< 

} 


ViewManager 是 一 个 视图 模块 的 入 口 ， 所 有 的 访问 都 是 通过 它 传递 
进来 的 ， 如 代码 清单 37-25 所 示 。 


代码 清单 37-25 视图 管理 


public class ViewManager { 
//Action 的 名 称 
private String actionName; 
// 当 前 的 值 栈 
private ValueStack valueStack = ValueStackHelper ,getValuesSt 
// 接 收 一 个 ActionName 
public ViewManager(String _actionName)t{ 
this.actionName = _actionName; 


} 
// 根 据 模型 的 返回 结果 提供 视图 
public String getViewPath(String result)t{ 
// 根 据 值 栈 查 找到 需要 提供 的 语言 
AbsLangData langData = new GBLangData(); 
// 根 据 action 和 result 查 找到 指定 的 视图 ， 并 加 载 语言 
AbsView view = new JspView(langData); 
// 返 回 视图 的 地 址 
return View,getURI( ) ; 








通过 桥梁 模式 我 们 把 不 同 的 语言 和 不 同类 型 的 视图 结合 起 来 ， 共 同 
提供 一 个 多 语言 的 应 用 系统 ， 即 使 以 后 增加 语言 也 非常 容易 扩展 。 








eA RR 








每 个 框架 或 项 目 都 有 大 量 的 工具 类 ，MVC 框 架 也 不 例外 。 先 来 看 
操作 XML 文 件 的 工具 类 ， 不 可 能 自己 读 写 XML 文 件 ， 我 们 使 用 DOM4J 
来 实现 ， 它 在 大 文件 的 处 理 上 性 能 很 有 优势 ， 而 且 比 较 简 单 ， 架 构 也 非 


常 优 秀 。 


使 用 DOM4J 从 XML 文 件 中 读 出 的 对 象 是 节点 〈Node) 、 元 素 
(Element) 、 属 性 〈Attribute) 等 ， 这 些 对 象 还 是 比较 容易 理解 的 ， 但 
是 不 能 保证 一 个 开发 组 的 人 对 这 些 都 了 解 ， 因 此 需要 把 它 转换 成 每 个 开 
发 成 员 都 理解 的 对 象 ， 比 如 我 们 处 理 这 样 一 段 XML 人 代码， 如 代码 清单 
37-26 所 示 。 


代码 清单 37-26 XML 文件 片段 


<action name="loginAction" class='"{ 类 名 全 路 径 y" method="execute"> 
<result name="success">/index2.jsp</result> 
<result name="fail">/index.jsp</result> 

</action> 


使 用 DOM4J 查 找到 该 节点 是 一 个 Node 对 象 ， 如 果 要 取得 属性 ， 就 
需要 转换 为 一 个 元 素 (Element) 对 象 ， 这 不 是 每 个 开发 成 员 都 能 理解 的 ， 
于 是 给 架构 师 提出 的 问题 就 是 ， 如 何 把 一 个 DOM4J 对 象 转换 成 自己 设 
计 的 对 象 。 答 案 是 适配器 模式 ， 我 们 首先 定义 一 个 Action 节 点 类 ， 如 代 
码 清单 37-27 所 示 。 


代码 清单 37-27 Action 节 点 类 


public abstract class ActionNode { 


//Action 的 名 称 


private String actionName; 


//Action 的 类 名 


private String actionClass; 








// 方 法 名 ， 默 认 是 execute 


private String methodName = "excuete"; 





// 视 图 路 径 


private String view; 


public String getActionName() { 


return actionName; 


public String getActionClass() { 


return actionClass; 


public String getMethodName() { 


return methodName; 


public abstract String getView(String Result); 
} 


它 是 一 个 抽象 类 ， 其 中 的 getView 是 一 个 抽象 方法 ， 是 根据 执行 结 
果 碍 找到 视图 路 径 。 只 要 编写 一 个 适配器 就 可 以 把 Elemet 对 象 转 为 
Action 贡 点 ， 如 代码 清单 37-28 所 示 。 





代码 清单 37-28 Action 节 点 


public class XmlActionNode extends ActionNode { 
// 需 要 转换 的 element 
private Element el; 





// 通 过 构造 函数 传递 


public XmlActionNode(Element _el)t{ 


this.el = _el; 


@Override 


public String getActionName( ){ 


return getAttValue("name"); 


Q@Override 


public String getActionClass(){ 


return getAttValue("class"); 


@Override 


public String getMethodName( ){ 


return getAttValue("method"); 


public String getView(String result)t{ 


ViewPathVisitor visitor = new ViewPathVisitor("success"); 


el.accept(visitor); 


return visitor.getViewPath(); 








// 获 得 指定 属性 值 








private String getAttValue(String attName){ 


Attribute att = elL.attribute(attName ) ， 


return att.getText(); 


这 是 一 个 对 象 适配器 ， 传 递 进来 一 个 Element 对 象 ， 把 它 转换 为 
ActionNode 对 象 ， 这 样 设计 以 后 ， 系 统 开 发 人 员 就 不 用 考虑 开源 工具 对 
系统 的 影响 ， 屏 蔽 了 工具 系统 的 影响 ， 这 是 一 个 典型 的 适 配 如 模式 应 
用 。 


不 知道 读者 是 否 注意 到 getView 方 法 ， 它 使 用 了 一 个 访问 者 模式 ， 
这 是 DOM4J 提 供 的 一 个 非常 优秀 的 API 接 口 ， 传 递 进去 一 个 访问 者 就 可 
以 遍历 出 我 们 需要 的 对 象 。 我 们 来 看 自己 定义 的 访问 者 ， 如 代码 清单 
37-29 所 示 。 


代码 清单 37-29 访问 者 


public class ViewPathVisitor extends VisitorSupport { 
// 获 得 指定 的 路 径 





private String ViewPath ; 


private String result; 





// 传 递 模型 结果 


public ViewPathVisitor(String _result)t{ 


result = _result,; 


Q@Override 


public void visit(Element el)t{ 


Attribute att = el.attribute("name"); 


if(att != nul1){ 


if(att.getName().equals("name") && att.getText().equals(result))t{ 


viewPath = el.getText(); 


} 


public String getViewPath(){ 


return viewPath; 


| 


DOM4J 提 供 了 VisitorSupport 抽 象 接口 ， 可 以 接受 元 素 、 市 辟 、 属 性 
等 访问 者 。 我 们 这 里 接受 了 一 个 元 素 访 问 者 ， 对 所 有 的 元 素 过 小 一 裔 ， 
然后 找到 目 己 需要 的 元 素 ， 非 常 强大 ! 











我 们 继续 分 析 ， 在 IoC 容 需 中 都 会 区 分 对 象 是 单 例 模式 还 是 多 例 模 
式 。 想 想 我 们 的 框架 ， 每 个 HTTP 请 求 都 会 产生 一 个 线程 ， 如 果 我 们 的 
Action 初 始 化 的 时 候 是 单 例 模式 会 出 现 什么 情况 ? 当 并 发 足够 多 的 时 候 
就 会 产生 阻 寨 ， 性 能 会 严重 下 降 ， 在 特殊 情况 下 还 会 产生 线程 不 安全 ， 
这 时 就 需要 考虑 多 例 情况 。 那 多 例 是 如 何 处 理 呢 ? 使 用 Clone 技 术 ， 首 
先 在 系统 启动 时 初始 化 所 有 的 Action， 然 后 每 过 来 一 个 请 求 就 拷贝 一 个 
Action， 减 少 了 初始 化 对 象 的 性 能 消耗 。 典 型 的 原型 模式 ， 但 问题 也 同 
时 产生 了 ， 并 发 较 多 时 ， 束 可 能 会 产生 内 存 洲 出 的 情况 ， 内 存 不 够 用 
了 ! 于 是 至 元 模式 束 可 以 上 场 了 ， 建 立 一 个 对 象 池 以 容纳 足够 多 的 对 
象 。 














37.2 最 佳 实践 


本 章 我 们 粗略 地 讲解 了 一 个 MVC 框 染 。 一 个 MVC 框 架 要 考虑 的 外 
界 环 境 因 素 太 多 了 ， 而 且 本 喘 MVC 框 架 也 是 一 个 轻 量 型 的 ， 就 是 希望 
我 们 编写 的 程序 在 没有 Struts、Spring MVC 等 框架 的 环境 中 不 需要 大 规 
模 的 修改 照样 能 够 运行 ， 所 以 编写 一 个 框架 不 是 一 件 容 易 的 事情 。 羊 运 
的 是 我 们 以 学 习 模 式 为 主 ， 通 过 设计 MVC 框 染 来 了 解 设计 模式 。 我 们 
来 看 看 本 章 用 到 了 哪些 模式 。 











e 工厂 方法 模式 : 通过 工厂 方法 模式 把 所 有 的 拦截 器 链 实现 出 来 ， 
方便 在 系统 初始 化 时 直接 处 理 。 


e 单 例 模 式 : Action 的 默认 配置 都 是 单 例 模式 ， 在 一 般 的 应 用 中 单 
例 已 经 足够 了 ， 在 复杂 情况 下 可 以 使 用 至 元 模式 提供 应 用 性 能 ， 减 少 单 
例 模式 的 性 能 隐患 。 


e 贡 任 链 模 式 : 建 并 拦截 器 链 以 及 过 滤 占 链 ， 实 现任 务 的 链条 化 处 
2 





e 人 迭代 右 模 式 ; 非常 方便 地 过 历 拦截 器 链 内 的 拦截 右 ， 而 不 用 再 目 
己 写 人 授 历 拦截 器 链 的 方法 。 


e 中 介 者 模式 : 以 核心 控制 器 为 核心 ， 其 他 同事 类 都 负责 为 核心 控 


制 器 “打工 ”， 保 证 核心 控制 吉 瘦 小 、 稳 定 。 


。 观 察 者 模式 ， 配 置 文件 修改 时 ， 不 用 重启 应 用 可 以 即刻 生效 ， 提 
供 使 用 者 的 体验 。 





e 桥梁 模式 ; 使 不 同 的 视图 配合 不 同 的 语言 文件 ， 为 终端 用 户 展 示 
不 同 的 界面 。 





e 宋 略 模式 : 对 XML 文件 的 检查 可 以 使 用 两 种 不 同 的 策略 ， 而 且 可 
以 在 测试 机 和 开发 机 中 使 用 不 同 的 检查 策略， 方便 系统 间 目 由 切换 。 


e 访问 者 模式 : 在 解析 XML 文件 时 ， 使 用 访问 者 非常 方便 地 访问 到 
需要 的 对 象 。 


e 适配器 模式 : 把 一 个 开发 者 不 熟悉 的 对 象 转换 为 熟悉 的 对 象 ， 避 
免 工具 或 框架 对 开发 者 的 影 啊 。 








e 门面 模式 : Action 分 发 右 负 责 所 有 的 Action 的 分 发 工作 ， 它 提供 
了 一 个 调用 Action 的 唯一 入 口 ， 避 免 外 部 模块 深入 到 模型 模块 内 部 。 


e 代理 便 式 : 大 量 使 用 动态 代理 ， 确 保 了 框架 的 智能 化 。 


MVC 框 杂 有 非常 成 熟 的 源码 ， 有 兴趣 的 读者 可 以 看 看 Struts、 
Spring MVC 等 源码 ， 其 中 包含 了 非常 多 的 设计 模式 。 该 源码 是 提高 设计 
技能 和 开发 技能 的 一 个 重要 途径 ， 看 一 本 书 是 与 作者 进行 了 一 次 心灵 交 








互 ， 看 一 份 源码 是 与 一 群 作者 进行 心灵 交互 ， 对 提高 自己 的 技术 修养 有 
非常 大 的 帮助 。 


第 38 章 “新 模式 


设计 模式 已 经 诞生 多 年 , “23? 这 个 数字 也 在 逐渐 变 大 ， 这 是 好 事 
情 ， 表 明 我 们 软件 界 正 在 积累 、 汇 编 我 们 的 知识 和 经 验 。 一 个 模式 的 提 
出 和 成 熟 需 要 一 段 时 间 ， 因 此 本 章 挑 选 了 5 个 大 家 时 第 使 用 ， 但 叉 经 党 
忽视 的 新 模式 进行 讲解 ， 即 规格 模式 、 对 象 池 模式 、 雇 工 模式 、 黑 板 模 
式 、 空 对 象 模式 。 希 望 这 5 个 新 模式 能 够 帮助 大 家 解决 更 多 的 实际 开发 


难题 。 





38.1 规格 模式 


38.1.1 规格 模式 的 实现 


不 知道 诸位 有 没有 使 用 C#3.5 做 过 开发 ， 它 有 一 个 非常 重要 的 新 特 
性 一 一 LINQ (Language INtegrated Query， 语 言 集成 查询 ) ， 它 提供 了 
类 似 于 SQL 语法 的 过 历 、 筛 选 等 功能 ， 能 完成 对 对 象 的 查询 ， 就 像 通 过 
SQL 语句 查询 数据 库 一 样 ， 例 如 这 样 的 一 个 程序 片段 : 





Dim DataList As String() = {"abc", "def", "ght"} 


Dim Result = From T As String In DataList Where T = "abc" 


这 人 句 话 的 意思 就 是 从 一 个 数组 中 碍 找 出 值 为 abc 的 元 素 ， 返 回 结果 
为 IEnumerable， 枚 举 嚣 类型。 注意 看 第 二 句 话 ， 它 使 用 了 类 似 SQL 的 
Select 语 法 结构 ，from、where 关 键 字 都 有 了 ， 而 且 还 文 持 类 似 的 
Orderby、Groupby 功 能 ， 很 强大 ， 有 兴趣 的 读者 可 以 查阅 有 关 资 料 。 那 
在 Java 世 界 中 是 个 也 存在 这 样 的 辅助 框架 呢 ? 有 ，JoSQL、Quaere 都 可 
以 提供 类 似 的 LINQ 语 言 ， 读 者 可 以 到 网 上 研究 一 下 JavaDoc， 同 样 非常 
简单 ， 功 能 强大 。 


我 们 今天 要 讲 的 主题 与 LINQ 有 很 大 关系 ， 它 是 实现 LINQ 的 核心 。 
想 想 SQL 语句 中 什么 是 最 复杂 的 ， 是 where 后 面 的 查询 条 件 ， 看 看 自己 


写 的 SQL 语句 基本 上 都 是 一 长 串 的 条 件 判 断 ， 中 间 一 堆 的 and、or、not 
逻辑 符 。 我 们 今天 的 任务 就 是 要 实现 条 件 语句 的 解析 ， 该 部 分 实现 了 ， 
基本 上 LINQ 语 法 已 经 实现 了 一 大 半 。 





我 们 以 一 个 案例 来 讲解 该 技术 ， 在 内 存 中 有 10 个 User 对 象 ， 根 据 不 
同 的 条 件 查 找 出 用 户 ， 比 如 姓名 包含 菜 个 字符 、 年 龄 小 于 多 少 岁 等 条 
件 ， 关 似 这 样 的 SQL: 





Select * From User where name like '% 国 庆 %' 


查找 出 姓名 中 包含 “国庆 ”两 个 字 的 用 户 ， 这 在 关系 型 数据 库 中 很 容 
易 实现 ， 但 是 在 对 象 群 中 怎么 实现 这 样 的 查询 呢 ? 好 ， 看 似 很 简单 ， 先 
设计 一 个 用 户 类 ， 然 后 提供 一 个 用 户 查 找 工具 类 ， 类 图 非常 容易 ， 如 图 
38-1 所 示 。 











很 简单 的 类 图 ， 有 一 个 用 户 类 ， 同 时 提供 了 一 个 操作 用 户 的 辅助 
类 ， 我 们 先 来 看 User 类 ， 如 代码 清单 38-1 所 示 。 






User 


<<interface>> 
IUserProvider 
c= 
+ArrayList fndUserByNameEqual(Strng name) 
+ArrayList findUserByAgeThan(int age) 









UserProvider 


图 38-1 简单 用 户 碍 询 类 网 


代码 清单 38-1 用 户 类 


public class User { 

// 姓 名 

private String name; 

// 年 龄 

private int age; 

public User(String _name,int _age)t{ 
this.name = _name; 
this.age = _age; 


| 
public String getName() { 
return name; 


public void setName(String name) { 
this.name = name， 


} 
public int getAge() { 
return age; 


public void setAge(int age) { 
this.age = age; 


} 
// 用 户 信息 打印 
Q@Override 





public String toString(){ 
return "用 户 名 : " + name+"\t 年 龄 : " + age; 
} 


User 束 是 一 个 简单 BO 业务 对 象 ， 再 来 看 用 户 操 作 接 口 ， 它 定义 一 
个 用 户 操 作 类 必须 具有 的 方法 ， 如 代码 清单 38-2 所 示 。 





代码 清单 38-2 用 户 操 作对 象 接口 


public interface IUserProvider { 
// 根 据 用 户 名 查找 用 户 
public ArrayList<User> findUserByNameEqual(String name); 
// 年 龄 大 于 指定 年 龄 的 用 户 
public ArrayList<User> findUserByAgeThan(int age); 








在 这 里 只 定义 了 两 个 查询 实现 ， 分 别 是 名 字 相 同 的 用 户 和 年 龄 大 于 
指定 年 龄 的 用 户 ， 大 家 都 知道 ， 相 似 的 查询 条 件 还 有 很 多 ， 比 如 名 字 中 
包含 指定 字符 、 年 龄 小 于 指定 年 龄 等 ， 我 们 仅 以 实现 这 两 个 查询 作为 代 
表 ， 如 代码 清单 38-3 所 示 。 








代码 清单 38-3 用 户 操作 类 


public class UserProvider implements IUserProvider { 
// 用 户 列表 
private ArrayList<User> USerList ; 
// 构 造 函 数 传 递 用 户 列表 
public UserProvider(ArrayList<User> _userList)t{ 
this.userList = _userList,; 


} 
// 年 龄 大 于 指定 年 龄 的 用 户 
public ArrayList<User> findUserByAgeThan(int age) { 
ArrayList<User> result = new ArrayList<User>(); 
for(User u:userList)t{ 
if(u.getAge()>age){ // 符 合 条 件 的 用 户 
result.add(u); 





} 
} 
return result,; 


} 
// 姓 名 等 于 指定 姓名 的 用 户 
public ArrayList<User> findUserByNameEqual(String name) { 
ArrayList<User> result = new ArrayList<User>(); 
for(User u:userList)t{ 
if(u,getName(),equals(name ) ){// 符 合 条 件 
result ,add(u) ， 
} 
} 


return result,; 














过 for 循 环 明 历 一 个 动态 数组 ， 判 断 用 户 是 否 符 合 条 件 ， 将 符合 条 








件 的 用 户 放置 到 另外 一 个 数组 中 ， 比 较 简单 。 我 们 编写 场景 类 来 模拟 该 
情景 ， 如 代码 清单 38-4 所 示 。 


代码 清单 38-4 场景 类 


public class Client { 


public static void main(String[] args) { 
// 首 先 初始 化 一 批 用 户 
ArrayList<User> userList = new ArrayList<User>() 
userList.add(new User(" 苏 大 "， 3)); 
userList.add(new User(" 牛 二 ", 8)); 
userList.add(new User(" 张 三 ", 10)); 
userList,.add(new User(" 李 四 ", 15)); 
userList.add(new User(" 王 五 ", 18)); 
UserList,add(new User(" 赵 六 ", 20)); 
userList.add(new User(" 马 七 ", 25)); 
userList,.,add(new User(" 杨 八 ", 30)); 
userList,.,add(new User(" 侯 九 ",35)); 
UserList,add(new User(" 布 十 ", 40)); 
// 定 义 一 个 用 户 查 询 类 
IUserProvider userProvider = new UserProvider(userLi 
// 打 印 出 年 龄 大 于 20 岁 的 用 户 
System.out.println("=== 年 龄 大 于 20 岁 的 用 户 ===")， 
for(User u:userProvider.findUserByAgeThan(20))t 

System.out.println(u); 








一 


运行 结果 如 下 所 示 : 


=== 年 龄 大 于 20 岁 的 用 户 === 
用 户 名 : 马 七 ”年 龄 ，25 
用 户 名 : 杨 八 年 龄 :30 
用 户 名 : 侯 九 年 龄 :35 
用 户 名 : 布 十 年 龄 : 40 


结果 非常 正确 ， 但 是 这 样 的 一 个 框架 基本 上 古 不 能 适应 业务 变化 
的 ， 为 什么 呢 ? 业务 变化 虽然 无 规则 ， 但 是 可 以 预 训 ， 比 如 我 们 这 个 得 
询 ， 今 天 要 俘 找 年 龄 大 于 20 岁 的 用 户 ， 明 天 要 查找 年 龄 小 于 30 岁 的 用 
户 ， 后 天 要 得 找 姓名 中 包含 “国庆 ?两 个 字 的 用 户 ， 想 想 看 IUserProvider 
接口 是 不 是 要 一 直 修 改 下 去 ? 接口 是 旭 约 ， 而 且 我 们 一 直 提倡 面 问 接口 
编程 ， 但 是 在 这 里 接口 竟然 都 可 以 修改 ， 是 不 是 发 现 设 计 有 很 大 问题 
了 1 




















问题 发 现 了 ， 就 要 想 办 法 解决 。 再 回顾 一 下 编写 的 代码 ， 注 意 看 
findUserByAgeThan 和 findUserByNameEqual 两 个 方法 ， 两 者 的 代码 有 什 
么 不 同 呢 ? 除了 站 后 面 的 判断 条 件 不 同 外 ， 就 没有 不 同 的 地 方 了 ， 我 们 
一 直 在 说 封装 变化 ， 这 两 段 程序 就 仅仅 有 这 一 个 变化 点 ， 我 们 是 不 是 可 
以 把 它 封装 起 来 呢 ? 完全 可 以 ， 把 它们 两 者 的 共同 点 抽取 出 来 ， 先 修改 


一 下 接口 ， 如 代码 清单 38-5 所 示 。 


代码 清单 38-5 修正 后 的 接口 


public interface IUserProvider { 
// 根 据 条 件 查 找 用 户 


public ArrayList<User> findUser(boolean condition); 


这 个 接口 的 设计 想法 非常 好 ， 但 是 参数 condition 很 难 实现 ， 看 看 
findUserByAgeThan、findUserByNameEqual 这 两 个 方法 ， 怎 么 才能 把 两 
者 的 不 同 点 设置 成 一 个 布尔 型 呢 ? 如 果 需 要 在 IUserProvider 对 象 外 判断 
后 传递 进来 ， 那 我 们 的 封装 就 没有 任何 意义 了 一 一 目前 为 止 ， 这 个 方案 
有 问题 了 。 





继续 考 夸 ， 既 然 不 能 在 封装 外 运算 ， 那 就 把 整个 条 件 都 进行 封装 ， 
由 IUserProvider 目 己 实现 运算 。 好 方法 ! 那 我 们 残 设 计 一 个 这 样 的 类 ， 
我 们 叫 它 规格 类 ， 什 么 意思 呢 ? 它 是 对 一 批 对 象 的 说 明 性 描述 ， 它 依照 
基准 判断 候选 对 象 是 否 满足 条 件 。 


思考 后 ， 我 们 设计 出 类 图 ， 如 图 38-2 所 示 。 


<<interface>> <<interface>> 
IUserProvider IUserSpecification 
| | 
+ArrayList findUser(IUserSpecification userSpec) +boolean isSatisfiedBy(User user) 
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姓名 相同 规格 ~ 年 龄 大 于 基准 规格 


图 38-2 加 入 规格 后 的 设计 类 图 





在 该 类 图 中 建立 了 一 个 规格 书 接口 ， 它 的 作用 就 是 定制 各 种 各 样 的 
规格 ， 比 如 名 字 相 等 的 规格 UserByNameEqual、 年 龄 大 于 基准 年 龄 的 规 
格 UserByAgeThan 等 ， 然 后 在 用 户 操作 类 中 采用 该 规格 进行 判断 。User 
类 没有 任何 改变 ， 如 代码 清单 38-1 所 示 ， 不 再 袭 述 。 

规格 书 接口 是 对 全 体 规 格 书 的 声明 定义 ， 如 代码 清单 38-6 所 示 。 

代码 清单 38-6 规格 书 接口 
public interface IUserSpecification { 


// 候 选 者 是 否 满足 要 求 
public boolean isSatisfiedBy(User user); 





} 
规格 书 接口 只 定义 一 个 方法 ， 判 断 候选 用 户 是 人 否 满 足 条 件 。 再 来 看 
姓名 相同 的 规格 书 ， 它 实现 了 规格 书 接口 ， 如 代码 清单 38-7 所 示 。 


代码 清单 38-7 姓名 相同 的 规格 书 


public class UserByNameEqual implements IUserSpecification { 
// 基 准 姓名 
private String name; 
// 构 造 函 数 传递 基准 姓名 
public UserByNameEqual(String _name){ 
this.name = _name,; 


} 

// 检 验 用 户 是 否 满足 条 件 

public boolean isSatisfiedBy(User user) { 
return user.getName().equals(name); 

} 


























代码 很 简单 ， 通 过 构造 函数 传递 进来 基准 用 户 名 ， 然 后 判断 候选 用 
户 是 否 匹 配 。 大 于 基准 年 龄 的 规格 书 与 此 类 似 ， 如 代码 清单 38-8 所 示 。 


代码 清单 38-8 大 于 基准 年 龄 的 规格 书 


public class UserByAgeThan implements IUserSpecification { 
// 基 准 年 龄 
private int age; 
// 构 造 函 数 传递 基准 年 龄 
public UserByAgeThan(int _age)t 
this.age = _age; 


} 

// 检 验 用 户 是 否 满足 条 件 

public boolean isSatisfiedBy(User user) { 
return user.getAge() > age; 

} 














规格 书 都 已 经 定义 完毕 ， 我 们 再 来 看 用 户 操 作 类 ， 先 看 用 户 操 作 的 
接口 ， 如 代码 清单 38-9 所 示 。 


代码 清单 38-9 用 户 操作 接口 


public interface IUserProvider { 
// 根 据 条 件 查 找 用 户 


public ArrayList<User> findUser(IUserSpecification userSpec) 


只 有 一 个 方法 一 一 根据 指定 的 规格 书 查 找 用 户 。 再 来 看 其 实现 类 ， 
如 代码 清单 38-10 所 示 。 


代码 清单 38-10 用 户 操 作 


public class UserProvider implements IUserProvider { 
// 用 户 列 表 
private ArrayList<User> userList; 
// 传 递 用 户 列 表 
public UserProvider(ArrayList<User> _userList)t{ 
this.userList = _userList,; 


} 

// 根 据 指定 的 规格 书 查找 用 户 

public ArrayList<User> findUser(IUserSpecification userSpec) 
ArrayList<User> result = new ArrayList<User>(); 
for(User u:userList)t{ 

if(userSpec,isSatisfiedBy(u) ){// 符 合 指定 规格 
result.add(u); 
} 

} 


return result,; 








程序 改动 很 小 ， 仅 仅 在 if 判断 语句 中 根据 规格 书 进 行 判断 ， 我 们 持 
续 地 扩展 规格 书 ， 有 多 少 得 询 分 类 束 可 以 扩展 出 多 少 个 实现 类 ， 而 
IUserProvider 则 不 需要 任何 改动 ， 它 的 一 个 方法 就 履 盖 了 我 们 刚刚 提出 
的 N 多 得 询 路 径 。 我 们 设计 一 个 场景 来 看 看 效果 如 何 ， 如 代码 清单 38-11 
所 示 。 











代码 清单 38-11 场景 类 


public class Client { 
public static void main(String[] args) { 
// 首 先 初始 化 一 批 用 户 


ArrayList<User> userList = new ArrayList<User>(); 


userList. 
userList. 
userList. 
userList. 
userList. 
userList. 
userList. 
userList. 
userList. 
userList. 


add(new 
add(new 
add(new 
add (new 
add(new 
add (new 
add(new 
add(new 
add(new 


User(" 苏 大 ", 3) ) ; 
User(" 牛 二 ", 8)); 
User(" 张 三 ", 10) 
User(" 李 四",15) 
User(" 王 五 ", 18) 
User ("站 六", 20)); 
User(" 马 七 ", 25) 
User(" 杨 八 ", 30) 
User(" 侯 九 ", 35 ) 


了 


党 


) 


add(new User(" 布 十 ", 40) 

// 定 义 一 个 用 户 查 询 类 

IUserProvider userProvider = new UserProvider(userLi 

// 打 印 出 年 龄 大 于 20 岁 的 用 户 

System.out.printlin("=== 年 龄 大 于 20 岁 的 用 户 ===")， 

// 定 义 一 个 规格 书 

IUserSpecification UserSpec = new UserByAgeThan(20); 

for(User u:userProvider.findUser(userSpec))t{ 
System.out.println(u); 

} 











在 场景 类 中 定义 了 一 个 规格 书 ， 
就 可 以 但 找到 上 自己 需要 的 用 户 了 ， 


然后 把 规格 书 提交 给 UserProvider 
行 结 果 相 同 ， 不 再 获 述 。 


缀 


大 家 想 想 看 ， 如 果 现 在 需求 变更 了 ， 比 如 需要 一 个 年 龄 小 于 基准 年 
龄 的 用 户 ， 该 怎么 修改 ? 增加 一 个 小 于 基准 年 龄 的 规格 书 ， 实 现 
IUserSpecification 接 口 ， 然 后 在 新 的 业务 中 调用 即 可 ， 别 的 什么 都 不 需 
要 修改 。 再 比如 需要 一 个 类 似 SQL 中 like 语 句 的 处 理 逻 辑 ， 这 个 也 不 
难 ， 如 代码 清单 38-12 所 示 。 


代码 清单 38-12 Like 规 格 书 


public class UserByNameLike implements IUserSpecification { 
//1ike 的 标记 
private final static String LIKE_ FLAG = "%"; 
// 基 准 的 like 字 符 串 
private String likestr; 
// 构 造 函 数 传递 基准 姓名 
public UserByNameLike(String _likeStr)t{ 

this.1likestr = _likeStr; 


} 
// 检 验 用 户 是 否 满 足 条 件 
public boolean isSatisfiedBy(User user) { 
boolean result = false; 
String name = user.getName( ) ; 
// 和 普 换 卸 % 后 的 干净 字符 串 
String str = likeStr.replace("%",""); 
// 是 以 名 字 开 头 ， 如 "国庆 %' 
if(1likeStr.endswith(LIKE_FLAG) && !likeStr.startswit 
result = name.startswith(str); 
}else if(1likeStr.startswith(LIKE_ FLAG) && !likeStr.e 
result = name.endsWith(str); 
}elsef{ 
result = name.contains(str); // 类 似 于 '% 国 庆 %' 
} 


return result,; 



































同时 ， 场 景 类 也 要 适当 地 改动 ， 毕 竟 业 务 已 经 发 生 了 变化 ， 高 层 模 
块 要 适应 这 种 变化 ， 如 代码 清单 38-13 所 示 。 


代码 清单 38-13 场景 类 


public class Client { 

public static void main(String[|] args) { 
// 首 先 初始 化 一 批 用 户 
ArrayList<User> userList = new ArrayList<User>() 
UserList,add(new User(" 苏 国庆 ", 23)); 
userList.add(new User(" 国 庆 和牛 ", 82)); 
userList.add(new User(" 张 国庆 三 ", 10)); 
userList.add(new User(" 李 四 ",10)); 
// 定 义 一 个 用 户 查 询 类 
IUserProvider userProvider = new UserProvider(userLi 
// 打 印 出 名 字 包 含 "国庆 "的 人 员 
System.out .println("=== 名 字 包 含 国庆 的 人 员 ===")， 








// 定 义 一 个 规格 书 

IUserSpecification userSpec = new UserByNameLike("%EE 

for(User u:userProvider.findUser(userSpec))t{ 
System.out.println(u); 

} 





-一 


运行 结果 如 下 所 示 : 


& 


=== 名 字 包 含 国庆 的 人 员 === 





用 户 名 : 苏 国 庆 ”年龄 : 23 
用 户 名 : 国庆 和 牛 年龄 :82 





用 户 名 : 张 国 庆 三 ”年 龄 ，10 


到 目前 为 止 ， 我 们 已 经 设计 了 一 个 可 扩展 的 对 象 查 询 平台 ， 但 是 我 
们 还 有 遗留 问题 未 解决 ， 看 看 SQL 语 句 ， 为 什么 where 后 面 会 很 长 ? 是 
因为 有 AND、OR、NOT 这 些 逻 辑 操 作 符 的 存在 ， 它 们 可 以 串联 起 多 个 
判断 语句 ， 然 后 整体 反馈 出 一 个 结果 来 。 想 想 看 ， 我 们 上 面 的 平台 能 
持 这 种 逻辑 操作 符 吗 ? 不 能 ， 你 要 说 能 ， 那 也 说 得 通 ， 需 要 两 次 过 滤 才 

能 实现 ， 比 如 要 找 名 字 包 含 “国庆 ”并 且 年 龄 大 于 25 岁 的 用 户 ， 代 码 该 怎 
么 修改 ? 如 代码 清单 38-14 所 示 。 











代码 清单 38-14 复合 查询 


public class Client { 
public static void main(String[|] args) { 
// 定 义 一 个 规格 书 
IUserSpecification UserSpec1 = new UserByNameLike("% 
IUserSpecification userSpec2 = new UserByAgeThan(20) 
userList = userProvider.findUser(userSpec1); 
for(User u:userProvider.findUser(userSpec2))t 





System.out.println(u); 


能 够 实现 ， 但 是 思考 一 下 程序 迎 辑 ， 它 采用 了 两 次 过 小 ， 也 就 是 两 
次 循环 ， 如 果 对 象 数 量 少 还 好 说 ， 如 果 对 象 数量 巨大 ， 这 个 效率 就 太 低 
了 ， 这 是 其 一 ;其 二 ， 组 合 方式 非常 多 ， 比 如 “与 “或 “ 非 ? 可 以 目 
由 组 合 ， 姓 名 中 包含 “国庆 ”但 年 龄 小 于 25 的 用 户 ， 姓 名 中 不 包含 国庆 但 
年 龄 大 于 25 岁 的 用 户 等 ， 我 们 还 能 如 此 设计 吗 ? 太 多 的 组 合 方式 ， 产 生 
组 合 爆炸 ， 这 种 设计 束 不 妥 了 ， 应 该 有 更 优 务 的 方案 。 





我 们 换个 方式 思考 该 问题 ， 不 管 是 AND 或 者 OR 或 者 NOT 操 作 ， 它 
们 的 返回 结果 都 还 是 一 个 规格 书 ， 只 是 逻辑 更 复杂 了 而 已 ， 这 3 个 操作 
符 只 是 提供 了 对 原 有 规格 书 的 复合 作用 ， 换 句 话 说， 规格 书 对 象 之 间 可 
以 进行 与 或 非 操 作 ， 操 作 的 结果 不 变 ， 分 析 到 这 里 ， 我 们 就 可 以 开始 修 
改 接口 了 ， 如 代码 清单 38-15 所 示 。 





代码 清单 38-15 带 与 或 非 的 规格 书 接口 


public interface IUserSpecification { 
// 候 选 者 是 否 满足 要 求 
public boolean isSatisfiedBy(User user); 
//and 操 作 
public IUserSpecification and(IUserSpecification spec); 
//or 操 作 
public IUserSpecification or(IUserSpecification spec); 
//not 操 作 
public IUserSpecification not(); 








在 规格 书 接口 中 增加 了 与 或 非 的 操作 ， 接 口 修改 了 ， 实 现 类 当然 也 
要 修改 。 先 全 面 思考 一 下 业务 ， 与 或 非 是 不 可 扩展 的 操作 ， 规 格 书 〈 也 
就 是 规格 对 象 ) 之 间 的 操作 只 有 这 三 种 方法 ， 是 不 需要 扩展 也 不 用 预 留 
扩展 空间 的 。 如 此 ， 我 们 就 可 以 把 与 或 非 的 实现 放 到 基 类 中 ， 那 现在 的 
问题 变 成 了 怎么 在 基 类 中 实现 与 或 非 。 注 意 看 它们 的 返回 值 都 需要 返回 
规格 书 类 型 ， 很 明显 ， 我 们 在 这 里 要 用 到 递归 调用 了 。 可 以 这 样 理解 ， 
基 类 需要 子 类 提供 业务 逻辑 支持 ， 因 为 基 类 是 一 个 抽象 类 ， 不 能 实例 化 
后 返回 ， 我 们 把 简单 类 图 画 出 来 ， 如 图 38-3 所 示 。 

















<<mterface>> 
IUserSpecification 





图 38-3 与 规格 的 示意 


基 类 对 子 类 产生 了 依赖 ， 然 后 进行 递归 计算 ， 大 家 一 定 会 及 出 这 样 
的 疑问 ， 父 类 怎么 可 能 依赖 子 类 ， 这 还 是 面向 接口 编程 吗 ? 想 想 看 ， 我 
们 提出 面向 接口 编程 的 目的 是 什么 ? 是 为 了 适应 变化 ， 拥 抱 变 化 ， 对 于 
不 可 能 发 生变 化 的 部 分 为 什么 不 能 固化 呢 ? 与 或 非 操 作 符号 还 会 增加 修 
改 吗 ? 规格 书 对 象 之 间 的 操作 还 有 其 他 吗 ? 思考 清楚 这 些 问 题 后 ， 答 案 








束 迎 为 而 解 了 。 








注意 ” 父 类 依赖 子 类 的 情景 只 有 在 非 第 明确 不 会 发 生变 化 的 场景 
中 存在 ， 它 不 具备 扩展 性 ， 是 一 种 固化 而 不 可 变化 的 结构 。 











析 完 毕 ， 我 们 设计 出 详细 的 类 图 ， 如 图 38-4 所 示 。 


> 


可 能 大 家 有 很 多 的 疑问 ， 我 们 先 来 分 析 代 码 ， 代 码 分 析 完 毕 估 计 能 
解决 你 大 部 分 的 疑问 。 规 格 书 接口 如 代码 清单 38-15 所 示 ， 不 再 于 述 。 
我 们 来 看 组 合 规格 书 (CompositeSpecification〉， 它 是 一 个 抽象 类 ， 实 
现 了 与 或 非 的 操作 ， 如 代码 清单 38-16 所 示 。 


代码 清单 38-16 组 合 规格 书 


public abstract class CompositeSpecification implements IUserSpec 
// 是 否 满足 条 件 由 实现 类 实现 
public abstract boolean isSatisfiedBy(User user); 
//and 操 作 
public IUserSpecification and(IUserSpecification spec) { 
return new AndSpecification(this, spec); 


} 
//not 操 作 
public IUserSpecification not() { 
return new NotSpecification(this); 


} 

//or 操 作 

public IUserSpecification or(IUserSpecification spec) { 
return new OrSpecification(this, spec); 

} 


<<mterface>> 


IUserSpecification 
规格 书 接口 一 一 
+boolean 1sSatisfiedBy(User user) 
+IUserSpecification and(IUSserSpecification spec) 
+IUserSpecification or(IUserSpecification spec) 
+IUserSpecification not() 











年 龄 大 于 基准 年 龄 
UserByAgeThan : 
[一 一 CompositeSpecification 
El 
UserByName Equal +IUserSpecification and(IUserSpecification spec) 


+IUserSpecification not() 
| - -| +IUserSpecification or(IUserSpecification spec) 
| \ 
姓名 相同 

















人 八 





NotSpecification 


图 38-4 完整 规格 书 类 图 











候选 对 象 是 否 满足 条 件 是 由 isSatisfiedBy 方 法 决定 的 ， 它 代表 的 是 
一 个 判断 逻辑 ， 由 各 个 实现 类 实现 。 三 个 与 或 非 操 作 在 抽象 类 中 实现 ， 
征 通过 直接 new 了 一 个 子 类 ， 如 此 设计 非常 符合 单一 职责 原则 ， 每 个 
子 类 都 有 一 个 独立 的 职责 ， 要 么 完成 “与 ?操作 ， 要 么 完成 “或 "操作 ， 要 
2 


成 “ 非 ” 操 作 。 我 们 先 来 看 “与 ”操作 规格 书 ， 如 代码 清单 38-17 所 示 。 








A 


代码 清单 38-17 与 规格 书 


public class AndSpecification extends CompositeSpecification { 


// 传 递 两 个 规格 书 进行 and 操 作 


private IUserSpecification left; 

private IUserSpecification right; 

public AndSpecification(IUserSpecification _left,IUserSpecif 
this.1left = left; 
this.right = _right; 


} 
// 进 行 and 运 算 
@Override 
public boolean isSatisfiedBy(User user) { 
return left.isSatisfiedBy(user) && right.isSatisfied 
} 


过 构造 函数 传递 过 来 两 个 需要 操作 的 规格 书 ， 然 后 通 
isSatisfiedBy 方 法 返回 两 者 and 操 作 的 结果 。 或 规格 书 和 非 规格 书 与 此 类 
似 ， 分 别 如 代码 清单 38-18、 代 码 清单 38-19 所 示 。 


代码 清单 38-18 或 规格 书 


public class OrSpecification extends CompositeSpecification { 
// 左 右 两 个 规格 书 
private IUserSpecification left; 
private IUserSpecification right; 
public OrSpecification(IUserSpecification _left,IUserSpecifi 
this.1left = _left,; 
this.right = _right; 


} 
//or 运 算 
@Override 
public boolean isSatisfiedBy(User user) { 
return left.isSatisfiedBy(user) || right.isSatisfied 
} 


代码 清单 38-19 非 规 格 书 


public class NotSpecification extends CompositeSpecification { 
// 传 递 一 个 规格 书 
private IUserSpecification spec; 
public NotSpecification(IUserSpecification _spec)t{ 
this.spec = _spec; 


} 

//not 操 作 

@Override 

public boolean isSatisfiedBy(User user) { 
return !spec.isSatisfiedBy(user); 

} 


这 三 个 规格 书 都 是 不 发 生变 化 的 ， 只 要 使 用 该 框架 ， 三 个 规格 书 都 
要 实现 的 ， 而 且 代 码 基本 上 是 雷同 的 ， 所 以 才 有 了 父 类 依赖 子 类 的 设 
计 ， 否 则 是 严禁 出 现 父 类 依赖 子 类 的 情况 的 。 大 家 再 仔细 看 看 这 三 个 规 
格 书 和 组 合 规 格 书 ， 代 码 很 简单 ， 但 也 很 巧妙 ， 它 跳出 了 我 们 面向 对 象 
设计 的 思维 ， 不 变 部 分 使 用 一 种 固化 方式 实现 。 








姓名 相同 、 年 龄 大 于 基准 年 龄 、Like 格 式 等 规格 书 都 有 少许 改变 ， 
把 实现 接口 变 为 继承 基 类 ， 我 们 以 名 字 相 等 规格 书 为 例 ， 如 代码 清单 
38-20 所 示 。 





代码 清单 38-20 姓名 相同 规格 书 


public class UserByNameEqual extends CompositeSpecification { 
// 基 准 姓名 
private String name; 
// 构 造 函 数 传 递 基 准 姓 名 
public UserByNameEqual(String _name){ 
this.name = _name， 


} 

// 检 验 用 户 是 否 满足 条 件 

public boolean isSatisfiedBy(User user) { 
return user.getName().equals(name); 

} 


























仅仅 修改 了 黑体 部 分 ， 其 他 没有 任何 改变 。 男 外 两 个 规格 书 修改 相 


同 ， 不 再 痪 ; 


述 。 其 他 的 User 及 UserProvider 没 有 任何 改动 ， 不 再 班 述 。 


我 们 修改 一 下 场景 类 ， 如 代码 清单 38-21 所 示 。 


代码 清单 38-21 场景 类 


public class 


Client { 


public static void main(String[] args) { 


// 首 先 初始 化 一 批 用 户 

ArrayList<User> userList = new ArrayList<User>() 

UserList,add(new User(" 苏 国庆 ", 23)); 

userList.,add(new User ("国庆 牛 ", 82)); 

userList.add(new User(" 张 国庆 三 ", 10)); 

userList.add(new User(" 李 由",10)); 

// 定 义 一 个 用 户 查 询 类 

IUserProvider userProvider = new UserProvider(userLi 

// 打 印 出 名 字 包 含 "国庆 "的 人 员 

System.out .println("=== 名 字 包 含 国庆 的 人 员 ===")， 

// 定 义 一 个 规格 书 

IUserSpecification spec = new UserByAgeThan(25); 

IUserSpecification spec2 = new UserByNameLike("% 国 庆 % 

for(User u:userProvider.findUser(spec.and(spec2)))t{ 
System.out.println(u); 

} 











在 场景 类 中 我 们 建立 了 两 个 规格 书 ， 一 个 是 年 龄 大 于 25 的 用 户 ， 驳 
一 个 是 名 字 中 包含 “国庆 ”两 个 字 的 用 户 ， 这 两 个 规格 书 之 间 的 关系 


是 “与 ”关系 5 


=== 名 字 包含 


运行 结果 如 下 : 


国庆 的 人 员 === 





用 户 名 : 国庆 牛 ”年龄 ，82 





到 此 为 止 我 们 的 LINQ 已 经 完成 了 很 大 一 部 分 了 ，SQL 语 句 中 的 
where 后 面部 分 已 经 可 以 解析 了 ， 完 全 可 以 再 增加 年 龄 相等 的 规格 书 、 


姓名 字数 规格 书 等 ， 你 在 SQL 中 使 用 过 的 条 件 在 这 里 者 能 实现 了 。 功 臣 
还 是 依赖 于 三 个 与 或 非 规 格 书 ， 有 了 它们 三 个 栋梁 才能 组 合 出 一 个 精彩 
的 条 件 查 询 世 界 。 


38.1.2 最 佳 实 践 
我 们 在 例子 中 多 次 提 到 规格 两 个 字 ， 该 实现 模式 就 叫做 规格 模式 


(Specification Pattern) ， 它 不 属于 23 个 设计 模式 ， 它 是 其 中 一 个 模式 
的 扩展 ， 是 哪个 模式 呢 ? 








我 们 用 全 局 的 观点 思考 一 下 ， 基 类 代表 的 是 所 有 的 规格 书 ， 它 的 目 
的 是 描述 一 个 完整 的 、 可 组 合 的 规格 书 ， 它 代表 的 是 一 个 整体 ， 其 下 的 
And 规 格 书 、Or 规 格 书 、Not 规 格 书 、 年 龄 大 于 基准 年 龄 规格 书 等 都 是 
一 个 真实 的 实现 ， 也 就 是 一 个 局 部 ， 现 在 我 们 又 回 到 了 整体 和 部 分 的 关 
系 了 ， 那 这 是 什么 模式 ? 对， 组 合 模式 ， 它 是 组 合 模式 的 一 种 特殊 应 
用 ， 我 们 来 看 它 的 通用 类 图 ， 如 图 38-5 所 示 。 


<<interface>> 


ISpecification 


+boolean isSatisfiedBy(Object candidate) 
+IUserSpecification and(IUserSpecification spec) 
+IUserSpecification or(lUserSpecification spec) 
+IUserSpecification not() 









Composite Specification 


三 ====== 半 = 
+IUserSpecification and(IUserSpecification spec) (< 
+IUserSpecification or(IUserSpecification spec) 

+IUserSpecification not() 


AndSpecification| |OrSpecification| | NotSpecification 

















BizSpecification 















图 38-5 规格 模式 通用 类 图 








为 什么 在 通用 类 图 中 把 方法 名 称 都 定义 出 来 呢 ? 是 因为 只 要 使 用 规 
格 模 式 ， 方 法 名 称 部 是 这 四 个 ， 它 是 把 组 合 模 式 更 加 具体 化 了 ， 放 在 一 
个 更 狭小 的 应 用 空间 中 。 我 们 再 仔细 看 看 ， 还 能 不 能 找到 其 他 模式 的 号 
影 ? 对 ， 策 略 模 式 ， 每 个 规格 书 都 是 一 个 集 略 ， 它 完成 了 一 系列 逻辑 的 
封闭 ， 用 年 龄 相等 的 规格 书 人 将 换 年 龄 大 于 指定 年 龄 的 规格 书 上 层 逻 辑 有 
什么 改变 吗 ? 不 需要 任何 改变 ! 











规格 模式 非常 重要 ， 它 巧妙 地 实现 了 对 象 科 选 功能 。 我 们 来 看 其 通 
用 源码 ， 首 先 看 抽象 规格 书 ， 如 代码 清 蛙 38-22 所 示 。 


代码 清单 38-22 抽象 规格 书 


public interface ISpecification { 
// 候 选 者 是 否 满足 要 求 
public boolean isSatisfiedBy(Object candidate); 








//and 操 作 
public ISpecification and(ISpecification spec); 
//or 操 作 
public ISpecification or(ISpecification spec); 
//not 操 作 


public ISpecification not(); 





组 合 规格 书 实现 与 或 非 的 算法 ， 如 代码 清单 38-23 所 示 。 





代码 清单 38-23 组 合 规格 书 


public abstract class CompositeSpecification implements ISpecific 
是 否 满足 条 件 由 实现 类 实现 
public abstract boolean isSatisfiedBy(Object candidate); 
//and 操 作 
public ISpecification and(ISpecification spec) { 
return new AndSpecification(this, spec); 














} 
//not 操 作 
public ISpecification not() { 
return new NotSpecification(this); 


} 
//or 操 作 


public ISpecification or(ISpecification spec) { 
return new OrSpecification(this, spec); 
} 


与 或 非 规 格 书 代码 分 别 如 代码 清单 38-24 至 代码 清单 38-26 所 示 。 


代码 清单 38-24 与 规格 书 


public class AndSpecification extends CompositeSpecification { 
// 传 递 两 个 规格 书 进 行 and 操 作 


private ISpecification left; 


private ISpecification right， 

public AndSpecification(ISpecification _left,ISpecification . 
this.1left = _left,; 
this.right = _right; 


} 
// 进 行 and 运 算 
@Override 
public boolean isSatisfiedBy(Object candidate) { 
return left.isSatisfiedBy(candidate) && right.isSati 
} 


代码 清单 38-25 或 规格 书 


public class OrSpecification extends CompositeSpecification { 
// 左 右 两 个 规格 书 
private ISpecification left; 
private ISpecification right; 
public OrSpecification(ISpecification _left,ISpecification _ 
this.left = _left,; 
this.right = _right; 


} 
//or 运 算 
@Override 
public boolean isSatisfiedBy(Object candidate) { 
return left.isSatisfiedBy(candidate) || right.isSati 
} 


代码 清单 38-26 非 规 格 书 


public class NotSpecification extends CompositeSpecification { 
// 传 递 一 个 规格 书 
private ISpecification spec; 
public NotSpecification(ISpecification _spec)t 
this.spec = _spec; 


} 

//not 操 作 

@Override 

public boolean isSatisfiedBy(Object candidate) { 
return !spec.isSatisfiedBy(candidate); 

} 


以 上 一 个 接口 、 一 个 抽象 类 、3 个 实现 类 只 要 在 适用 规格 模式 的 地 
方 都 完全 相同 ， 不 用 做 任何 的 修改 ， 大 家 闭 看 眼 照 抄 就 成 ， 要 修改 的 是 
下 面 的 规格 书 





代码 清单 38-27 业务 规格 书 


public class BizSpecification extends CompositeSpecification { 
// 基 准 对 象 
private Object obj; 
public BizSpecification(Object _obj)t{ 
this.obj = _obj; 
} 


@Override 
public boolean isSatisfiedBy(Object candidate) { 
// 根 据 基 准 对 象 和 候选 对 象 ， 进 行业 务 判断 ， 返 回 boolean 


return false; 














然后 就 是 看 怎么 使 用 了 ， 场 景 类 如 代码 清单 38-28 所 示 。 


代码 清单 38-28 场景 类 


public class Client { 
public static void main(String[|] args) { 

// 待 分 析 的 对 象 

ArrayList<Object> list = new ArrayList<Object>(); 

// 定 义 两 个 业务 规格 书 

ISpecification spec1 

ISpecification spec2 

// 规 则 的 调用 

for(Object obj:1list)t{ 
if(speci.and(spec2).isSatisfiedBy(obj)){ // 

System.out.println(obj); 


new BizSpecification(new Obje 
new BizSpecification(new Obje 





规格 模式 已 经 是 一 个 非常 具体 的 应 用 框架 了 相对 于 23 个 设计 模 
式 ) ， 大 家 遇 到 类 似 多 个 对 象 中 筛选 查找 ， 或 者 业务 规则 不 适 于 放 在 任 
何 已 有 实体 或 值 对 象 中 ， 而 且 规则 的 变化 和 组 合 会 掩 兰 那 些 领域 对 象 的 
基本 含义 ， 或 者 是 想 上 自己 编写 一 个 类 似 LINQ 的 语言 工具 的 时 候 就 可 以 
照搬 这 部 分 代码 ， 只 要 实现 自己 的 逻辑 规格 书 即 可 。 

















38.2 对 象 池 模式 


上 周二 ， 师 兄 过 来 找 我 ， 他 负责 运 维 一 个 大 型 新 闻 网 站 ， 说 是 网 站 
出 现 性 能 ， 让 我 帮忙 分 析 调 优 。 我 这 儿 天 正好 内 得 手 痒 ， 同 时 又 卖 个 人 
情 ， 何 乐 而 不 为 呢 。 于 是 我 们 俩 就 到 机 房 足 点 ， 奶 碍 问题 。 











38.2.1 正确 的 池 化 


简单 次 明 一 下 该 系统 的 场景 ， 这 是 一 个 专业 的 新 闻 奶 踪 网 站 ， 关 注 
的 是 专业 新 闻 的 深度 ， 在 行业 内 具有 相当 大 的 影响 力 。 最 近 一 段 时 间 凡 
出 现 偶 友 性 缓慢 ， 从 监控 情况 上 看 ， 啊 应 时 间 在 2 秒 以 上 ， 由 于 最 近 软 
便 件 环境 都 没有 变更 过 ， 因 此 直觉 判断 : 节 快 捷 、 直 观 的 解决 方案 就 是 
增加 DB 人 硬件 设备 。 但 由 于 东家 是 穷 惯 了 ， 不 同意 在 没有 彻 查 问题 之 前 
而 依靠 增强 硬件 来 解决 问题 ， 于 是 我 们 这 些 软件 工程 师 就 忙活 起 来 了 。 














网 站 首页 内 容 基 本 都 是 静态 的 〈 轮 询 生成 ) ， 唯 一 的 动态 部 分 是 网 
站 的 激励 语 ， 比 如 “ 积 一 时 之 哇 步 ， 钳 干 里 之 示 程 "””“ 业 精 于 勤 ， 苞 于 
嬉 ， 行 成 于 思 ， 毁 于 随 ” 等 励志 语句 ， 这 是 一 个 简单 的 SQL 随 机 查询 结 
果 ， 表 中 的 数量 在 5000 条 左右 ， 而 且 结 构 简 单 ， 人 查询 性 能 不 是 问题 。 示 
例 代 码 如 代码 清 蛙 38-29 所 示 。 


代码 清单 38-29 无 绥 存 的 SQL 随 机 读 取 


@Service 
public class WisdomProvider { 
Q@Autowire 
private WisdomDao wisdomDao; 
public String getOneWord() { 
return wisdomDao.randomOneWisdom( ); 
} 


对 于 代码 中 的 @Service、@Autowire 注 解 ， 做 过 Spring 开 发 的 都 
懂 ， 这 是 一 个 典型 的 三 层 架 构 ，WisdomDao 的 randomOneWisdom 方 法 是 
通过 数据 库 随机 函数 查询 一 条 记录 。 在 跟踪 过 程 中 ， 发 现 高 峰 期 数据 库 
连接 偶尔 出 现 占 满 情况 ， 而 且 都 是 查询 该 表 〈 顺 便 说 下 ， 该 数据 库 的 随 
机 查询 算法 有 缺陷 ) ， 问 题 找到 了 : 每 一 次 访问 都 会 直接 但 询 数据 库 ， 
没有 组 在。 通常 情况 下 ， 这 没有 问题 ， 但 是 在 高 并 发 的 情况 下 ， 例 如 在 
10 万 PV 的 压力 下 服务 器 基本 就 垮 控 了， 这 是 非常 严重 的 问题 。 























么 解决 昵 ?” 好 办 ， 引 入 一 个 对 象 池 ， 把 这 5000 条 记录 (根据 评估 
最 多 不 超过 20000 条 记录 ) 在 启动 时 直接 加 载 到 内 存 中 ， 在 需要 时 再 从 
内 存 中 取得 ， 以 后 查询 不 再 与 数据 库 交 互 。 示 例 代 码 如 代码 清单 38-30 
所 示 。 





代码 清单 38-30 增加 缓存 后 的 随机 读 取 


@Service 
public class WisdomProvider { 
Q@Autowire 
private WisdomDao wisdomDao; 
private List<String> wisdoms = null; 
@PostConstruct 
public void init() { 
wisdoms = wisdomDao.getAll(); 


} 
public String getoneword ( ) 

return RandomUtils.getOne(wisdoms); 
} 








(@PostConstruct 注 解 的 作用 是 Spring 容 器 在 启动 完毕 后 ， 直 接 执 行 
init 方 法 ， 一 次 性 读 取 所 有 的 数据 ， 然 后 在 应 用 运行 期 间 不 再 与 数据 库 
交互 ， 直 接 从 List 列 表 中 获取 数据 。 通 过 这 样 的 修正 ， 系 统 性 能 有 了 大 
幅 提升 ， 在 不 增加 硬件 的 情况 下 ， 彻 底 解决 了 性 能 问题 。 这 就 是 对 象 池 
模式 。 








38.2.2 对 象 池 模 式 的 意图 


对 象 池 模式 ， 或 者 称 为 对 象 池 服务 ， 其 意图 如 下 : 


通过 循环 使 用 对 象 ， 减 少 资源 在 初始 化 和 释放 时 的 昂贵 损耗 由 。 





注 章 ”这 里 的 “昂贵 " 可 能 是 时 间 效 益 〈 如 性 能 ) ， 也 可 能 是 空间 效 
益 《 如 并 行 处 理 ) ， 在 大 多 的 情况 下 , “昂贵 ? 指 性 能 


个 请 求 。 典 型 例子 是 连接 池 和 线程 池 ， 这 是 我 们 开发 中 经 常 接触 到 的 。 
类 图 如 图 38-6 所 示 。 


ObjectPool 


十 CheckOut( ) 
十 CheckIn() 





图 38-6 对 象 池 模式 通用 类 图 


对 象 池 提 供 两 个 公共 的 方法 : checkOut 负 责 从 池 中 提取 对 象 ， 
checkImn 负 贡 把 回收 对 象 〈 当 然 ， 很 多 时 候 checkIn 已 经 目 动 化 处 理 ， 不 
需要 显 式 声明 ,如 连接 池 ) ， 对 象 池 代码 如 代码 清单 38-31 所 示 。 


代码 清单 38-31 对 象 池 示 例 代码 


public abstract class ObjectPool<T> { 
// 容 器 ， 容 纳 对 象 
private Hashtable<T, ObjectStatus> pool = new Hashtable<T 
// 初 始 化 时 创建 对 象 ， 并 放 入 到 池 中 
public ObjectPool() { 
pool.put(create(), new ObjectStatus() ) ; 








} 
// 从 Hashtable 中 取出 空 闪 元 素 
public synchronized T checkOut() { 
// 这 是 最 简单 的 策略 
for (Tt : pool.keySet()) { 
if (pool.get(t).validate()) { 
pool.get(t).setUsing(); 
return 七 ， 





} 
} 
return null; 


} 

// 归 还 对 象 

public synchronized void checkIn(T t) { 
pool.get(t).setFreel(); 


} 
class ObjectStatus { 


// 占 用 
public void setUsing() { 


} 
// 释 放 
public void setFree() - 
// 注 意 : 阁 T 是 有 状态 ， 则 需要 回归 到 初始 化 状态 


l， 

// 检 查 是 否 可 用 

public boolean validate() { 
return false; 

站 


上 
// 创 建 池 化 对 象 
public abstract T create() 

















这 是 一 个 简单 的 对 象 池 实 现 ， 在 实际 应 用 中 还 需要 考虑 池 的 最 小 
值 、 最 大 值 、 池 化 对 象 状态 (大 有 的 话 ， 需 要 重点 考虑 ) 、 腊 向 处 理 
《如 满 池 情 况 ) 等 方面 ， 特 别 是 池 化 对 象 状 态 ， 若 是 有 状态 的 业务 对 象 
则 需要 重点 关注 。 


38.2.3 最 佳 实践 
把 对 象 池 化 的 本 意 是 期 望 一 次 性 初始 化 所 有 对 象 ， 减 少 对 象 在 初始 


化 上 的 昂贵 性 能 开销 ， 从 而 提高 系统 整体 性 能 。 然 而 池 化 处 理 本 映 也 要 
付出 代价 ， 因 此 ， 并 非 任何 情况 下 都 适合 采用 对 象 池 化 。 





通常 情况 下 ， 在 重复 生成 对 象 的 操作 成 为 影响 性 能 的 关键 因 系 时 ， 
才 适 合 进行 对 象 池 化 。 但 是 知 池 化 所 能 带 来 的 性 能 提高 并 不 显 乾 或 重要 
的 话 ， 建 议 帮 弃 对 象 池 化 技术 ， 以 保持 代码 的 简明 ， 转 而 使 用 更 好 的 硬 
件 来 提高 性 能 为 佳 。 


对 象 池 技术 在 Java 领 域 已 经 非常 成 熟 ， 只 要 做 过 企业 级 开发 的 人 
员 ， 基 本 都 用 过 C3P0、DBCP、Proxool 等 连接 池 ， 也 配置 过 
minPoolSize、maxPoolSize 等 参数 ， 这 是 对 象 池 模 式 的 典型 应 用 。 在 实 
际 开 发 中 知 需 要 对 象 池 ， 建 议 使 用 common-pool 工 具 包 来 实现 ， 人 简单 、 
快捷 、 高 效 。 


[1] 原文 是 Avoid expensive acquisition and release of resources by recycling 


objects that are no longer in use。 


38.3 雇工 模式 


6.51 屠 工 间作 





我 是 一 个 富 聚 (当然 只 是 想象 中 的 ) ， 家 里 有 很 多 佣 人 ， 家 务 活 基 
本 上 不 用 我 动手 ， 我 只 要 动 动 口 束 可 以 了 ， 在 这 里 每 个 人 都 有 不 同 分 
工 ， 我 可 以 指挥 厨师 把 厨房 并 干净 ， 这 是 他 的 地 盘 ; 我 可 以 指挥 园丁 把 
花园 收拾 和 干净、 漂亮 ， 这 是 他 应 该 做 的 ， 我 还 可 以 让 裁缝 把 我 的 衣服 收 
拾 干将。 注意 看 ， 我 这 里 列举 出 的 三 个 对 象 〈 厨 师 、 团 丁 、 裁 缝 ) 都 共 
有 相同 的 功能 清洁。 从 男 一 方面 说 ， 厨 房 、 花 园 、 衣 服 都 具有 被 清洁 
的 特性 ， 我 们 从 这 一 例子 入 手 ， 编 写 代 码 如 代码 清单 38-32 所 示 。 








代码 清单 38-32 三 个 对 象 的 被 清洁 特质 


// 可 以 被 清洁 的 对 象 

public interface Cleanable { 
// 被 清洁 
public void celaned(); 


} 
// 北 园 
class Garden implements Cleanablet{ 
public void celaned(){ 
System.out.println(“ 花 园 被 清洁 干净 ”)， 


上 
// 厨 房 
class Kitchen implements Cleanablef{ 
public void celaned(){ 
System.out .println(“ 言 房 被 清洁 干净 ”)， 


// 衣 服 
class Cloth implements Cleanablef{ 
public void celaned(){ 
System.out.,println(“ 衣 服 被 清洁 干净 ”); 





三 个 对 象 ( 厨 房 、 花 园 、 衣 服 〉 的 共同 特征 抽取 出 来 ， 同 时 也 需要 
把 厨师 、 裁 颖 、 园 丁 的 共同 特征 也 抽象 出 来 。 从 我 这 个 主人 的 角度 看 
来 ， 他 们 三 者 都 是 清洁 者 ， 只 是 输入 的 对 象 不 同 而 已 ， 如 代码 清单 38- 
33 所 示 。 





代码 清单 38-33 抽象 的 清洁 者 


public class Cleaner { 
// 清 洁 
public void clean(Cleanable clean)t{ 
clean.celaned( ); 
} 


非常 简单 ， 束 这 么 一 个 清洁 者 束 可 以 厨师 、 园 本 、 裁 颖 。 我 们 再 编 
写 一 个 场景 类 ， 描 述 一 下 发 生 了 什么 事 ， 如 代码 清单 38-34 所 示 。 


代码 清单 38-34 场景 类 


public class Client { 
public static void main(String[|] args) { 

// 厨 师 清 洁 厨 房 
Cleaner cookie = new Cleaner(); 
cookie.clean(new Kitchen( )); 
// 园 丁 清洁 花园 
Cleaner gardener = new Cleaner(); 
gardener.clean(new Garden()); 
// 裁 颖 清洁 衣服 
Cleaner tailer = new Cleaner(); 
tailer.clean(new Cloth()); 














场景 写 完 了 ， 运 行 一 下 ， 就 可 以 看 到 厨师 打扫 了 厨房 ， 园 丁 清洁 了 
花园， 裁缝 清洁 了 衣服 。 代 码 很 简单 ， 但 是 诸位 有 没有 发 觉 这 和 我 们 通 
常 的 分 析 是 不 同 的 。 通 常 的 做 法 是 : 既然 厨师 、 园 丁 、 裁 颖 都 具有 清洁 
的 功能 ， 那 就 定义 一 个 接口 描述 三 者 的 清洁 功能 ， 然 后 再 定义 三 个 类 ， 
分 别 代 表 厨 师 、 园 丁 、 裁 缝 实现 这 个 接口 。 这 是 一 种 常用 的 解雇 办 法 ， 
可 以 解决 该 问题 ， 但 今天 我 们 从 另外 一 个 侧面 进行 分 析 ， 引 出 一 个 新 的 
模式 :雇工 模式 。 








38.3.2 雇工 模式 的 意图 


雇工 模式 也 叫做 仆人 模式 〈Servant Design Pattern) ， 其 意图 是 : 





雇工 模式 是 行为 模式 的 一 种 ， 它 为 一 组 类 提供 通用 的 功能 ， 而 不 需 
实现 这 些 功能 ， 它 是 命令 模式 的 一 种 扩展 品 。 


看 看 我 们 的 例子 ， 厨 师 、 裁 终 、 园 丁 是 一 组 类 ， 都 具有 清洁 的 能 
力 ， 但 是 我 们 却 没 实现 ， 而 是 采用 一 种 更 优雅 的 方式 来 实现 ， 这 就 是 雇 
工 模 式 。 雇 工 模式 的 类 图 如 图 38-7 所 示 。 





<<interface> > 
IServiced 





图 38-7 雇工 模式 通用 类 图 


在 类 图 中 ，IServiced 是 用 于 定义 “一 组 类 ”所 具有 的 功能 ， 其 示例 代 
码 如 代码 清单 38-35 所 示 。 


代码 清单 38-35 通用 功能 


public interface IServiced { 
// 具 有 的 特质 或 功能 
public void serviced(); 








针对 不 同 的 服务 对 象 具备 不 同 的 服务 内 容 ， 也 就 是 具体 的 功能 实现 
IServiced 接 口 即 可 ， 示 例 代 码 如 代码 清单 38-36 所 示 。 





代码 清单 38-36 定义 具体 功能 


public class Serviced1 implements IServiced { 
public void serviced()t{ 


} 


public class Serviced2 implements IServiced{ 
public void serviced(){ 


功能 定义 完毕 后 ， 我 们 需要 由 一 个 雇工 来 执行 这 些 功 能 。 简 单 地 
说 ， 就 是 需要 有 一 个 执行 者 ， 可 以 把 一 组 功能 聚集 起 来 ， 示 例 代 码 如 代 
码 清单 38-37 所 示 。 


代码 清单 38-37 雇工 类 


public class Servant { 
// 服 务 内 容 
public void service(IServiced serviceFuture)t{ 
serviceFuture.serviced( ); 
} 


在 整个 雇工 模式 中 ， 所 有 上 有 具有 IServiced 功 能 的 类 可 以 实现 该 接口 ， 
然后 由 雇工 类 Servant 进 行 集合 ， 完 成 一 组 类 不 用 实现 通用 功能 而 具有 相 
应 职能 的 目的 。 


38.3.3 最 佳 实践 


在 日 常 的 开发 过 程 中 ， 我 们 可 能 已 经 接触 过 雇工 模式 ， 只 是 我 们 没 
有 把 它 抽 取出 来 ， 也 没有 汇编 成 册 。 或 许 大 家 已 经 看 出 这 与 命令 模式 非 
各 相似 ， 读 者 可 以 回顾 第 15 章 ， 会 发 现 雇工 模式 是 命令 人 模式 的 一 种 简 
化 ， 但 它 更 符合 我 们 实际 的 需要 ， 更 容易 引入 开发 场景 中 。 














[1] 原文 是 A behavioral pattern used to offer some functionality to a group of 


classes without defining that functionality in each of them 。 


38.4 黑板 模式 
38.4.1 黑板 模式 的 意图 


黑板 模式 (Blackboard Design Pattern) 是 观察 者 模式 的 一 个 扩展 ， 
知名 度 并 不 高 ， 但 是 我 们 使 用 的 范围 却 非常 广 。 黑 板 模式 的 意图 如 下 : 
允许 消息 的 读 写 同时 进行 ,广泛 地 交互 消息 多。 


简单 地 说 ， 黑 板 模式 允许 多 个 消息 读 写 者 同时 存在 ， 消 息 的 生产 者 
和 消费 者 完全 分 开 。 这 就 像 一 个 黑板 ， 任 何 一 个 教授 〈 消 息 的 生产 者 ) 
都 可 以 在 其 上 书写 消息 ， 任 何 一 个 学 生 〔〈 消 息 的 消费 者 ) 都 可 以 从 黑板 
上 读 取 消息 ， 两 者 在 空间 和 时 间 上 可 以 解 厢 ， 并 且 互 不 干扰 。 示 意图 如 
图 38-8 所 示 。 


消息 生产 者 > | Eee 一 一 > | 消息 消费 者 2 





消息 消费 者 … 





图 38-8 黑板 模式 示意 图 


看 到 这 个 图 大 家 可 能 会 说 : 这 不 是 一 个 简单 的 消 妃 广播 吗 ? 是 的 ， 
确实 如 此 ， 黑 板 模式 确实 是 消息 的 广播 ， 主 要 解决 的 问题 是 消息 的 生产 
者 和 消费 者 之 间 的 耦合 问题 ， 它 的 核心 是 消 乱 存储 《黑板 ) ， 它 存储 所 
有 消 轧 ， 并 可 以 随时 被 读 取 。 当 消息 生产 者 把 消 轧 写 入 到 消息 仓库 后 ， 
其 他 消费 者 就 可 以 从 仓库 中 读 取 。 当 然 ， 此 时 消息 的 写 入 者 也 可 以 变 身 
为 消 妃 的 阅读 者 ， 读 写 者 在 时 间 上 解 奈 。 对 于 这 些 消 电 ， 消 费 者 只 需要 
关注 特定 消 轧 ， 不 处 理 与 上 自己 不 相关 的 消 轧 ， 这 一 点 通 负 通过 过 滤器 来 
实现 。 























38.4.2 黑板 模式 的 实现 方法 


黑板 模式 一 般 不 会 对 架构 产生 什么 影响 ， 但 它 通 常会 要 求 有 一 个 清 
晰 的 消 妃 结构 。 黑 板 模式 一 般 都 会 提供 一 系列 的 过 滤器 ， 以 便 消 妃 的 消 
费 者 不 再 接触 到 与 自己 无 关 的 消息 。 在 实际 开发 中 ， 黑 板 模式 常见 的 有 
两 种 实现 方式 。 


e 数据 库 作为 黑板 


利用 数据 库 充当 黑板 ， 生 产 者 更 新 数据 信忠， 不同 的 消费 者 共 译 数 
据 库 中 信息 ， 这 是 最 常见 的 实现 方式 。 该 方式 在 技术 上 容易 实现 ， 开 发 
量 较 少 ， 熟 悉 度 较 高 。 缺 点 是 在 大 量 消 息 和 高 频率 访问 的 情况 下 ， 人 性 能 
会 受到 一 定 影 响 。 














在 该 模式 下 ， 消 恳 的 读 取 是 通过 消费 者 主动 * 拉 取 ”， 因 此 该 模式 也 
叫做 “ 拉 模 式 ”。 


e 消息 队列 作为 黑板 


以 消息 队列 作为 黑板 ， 通 过 订阅 -发 布 模型 即 可 实现 黑板 模式 。 这 
也 是 黑板 模式 被 淡忘 的 一 个 重要 原因 : 消息 队列 〈Message Queue) 已 
经 非常 普及 了 ， 做 Java 开 发 的 已 经 没有 几 个 不 知道 消 居 队列 的 。 


在 该 模式 下 ， 消 费 者 接收 到 的 消息 是 被 主动 推送 过 来 的 ， 因 此 该 模 
式 也 称 为 “ 推 模式 ”。 





提示 。 黑板 模式 不 做 详细 讲解 ， 因 为 我 们 现在 已 经 在 大 量 使 用 消 
恩 队 列 ， 既 可 以 做 到 消息 的 同步 处 理 ， 也 可 以 实现 异步 处 理 ， 相 信 大 家 
己 经 在 开发 中 广泛 使 用 了 ， 它 已 经 成 为 跨 系 统 交 互 的 一 个 事实 标准 了 。 





[1] 原文 是 allows multiple readers and writers. Communicates information 


system-wide。 


38.5 空 对 象 模 式 


空 对 象 模式 (Null Object Pattern ) 是 通过 实现 一 个 默认 的 无 意义 对 
象 来 避免 null 值 出 现 ， 简 单 地 说 ， 就 是 为 了 避免 在 程序 中 出 现 null 值 判断 
而 诞生 的 一 种 常用 设计 方法 。 


38.5.1 空 对 象 模式 的 例子 


举 个 简单 的 例子 来 说 明 ， 我 们 写 一 个 听 动 物 叫 声 的 模拟 程序 ， 如 代 
码 清 单 38-38 所 示 。 


代码 清单 38-38 动物 叫 声 


// 定 义 动 物 接口 
public interface Animal { 
public void makeSound ( ) ; 


} 
// 定 义 一 个 小 狗 
class Dog implements Animaltf{ 


public void makeSound( ){ 
System.out.println(“Wang Wang Wang!”); 


然后 再 定义 一 个 人 来 听 动 物 的 叫 声 ， 如 代码 清单 38-39 所 示 。 
代码 清单 38-39 听 动 物 叫 声 的 人 


public class Person { 
// 听 到 动物 叫 声 


public void hear(Animal animal)t{ 
if(animal !=null)t{ 
animal.makeSound(); 


也 许 你 觉得 程序 没有 什么 问题 ， 输 入 参数 animal 是 应 该 做 空 值 判 
断 。 但 是 ， 我 们 这 样 思 考 : 在 一 个 完整 的 系统 中 ，animal 对 象 是 如 何 产 
生 ? 什么 原因 会 产生 null 值 ?如果 我 们 能 够 控制 住 null 值 的 产生 ， 是 不 是 
就 可 以 去 掉 这 个 空 值 判断 了 ? 那 这 样 ， 程 序 是 不 是 更 易 读 更 简单 ? 好 ， 
我 们 就 编写 一 个 更 完美 的 程序 ， 增 加 一 个 NullAnimal 类 ， 如 代码 清单 38- 
40 所 示 。 

















代码 清单 38-40 增加 一 个 NullAnimal 


class NullAnimal implements Animalf{ 
public void makeSound(){ 


增加 了 NullAnimal 类 后 ， 在 Person 类 中 就 不 需要 "animal!=null" 这 句 
话 了 ， 因 为 我 们 提供 了 一 个 实现 接口 的 所 有 方法 ， 不 会 再 产生 null 对 
象 。 想 象 一 个 Web 项 目 中 ，animal 对 和 象 可 能 由 MVC 框 染 映 射 产 生 ， 我 们 
只 要 定义 一 个 默认 的 映射 对 象 是 NullAnimal， 就 可 以 解决 空 值 判断 的 问 
题 ， 提 升 代码 的 可 读 性 。 这 就 是 空 对 象 模式 (一 些 项 目 组 把 它 作 为 编码 
规范 的 一 部 分 ) ， 非 常 简单 ， 但 非常 实用 。 





38.5.2 最 佳 实 践 





空 对 象 模 式 是 通过 空 代 码 实现 一 个 接口 或 抽象 类 的 所 有 方法 ， 以 满 
足 开发 需求 ， 简 化 程序 。 它 如 此 简单 ， 以 全 于 我 们 经 利 在 代码 中 看 到 和 
使 用 ， 对 它 己 经 熟视无睹 了 ， 而 它 无 论 是 事前 规划 或 事后 重 构 ， 都 不 会 
对 我 们 的 代码 产生 太 大 冲击 ， 这 也 是 我 们 “ 瑶 视 ? 它 的 根本 原因 。 











附录 “23 种 设计 模式 彩 图 
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